<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 25, 2015 at 1:19 PM, Richard Whittaker <span dir="ltr"><<a href="mailto:richard@avits.ca" target="_blank">richard@avits.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2015-02-25 09:57, SilverTip257 wrote:<br>
<br>
Here's some captures from one of my "near" hosts to one of the non working "far" hosts...<br><br></blockquote><div><br></div><div style>Those packet captures appear to indicate no problems.  Established TCP session and so forth.</div><div style><br></div><div style>I believe it would be better for you to tell tcpdump not to resolve host names -n (you could do the same for ports if you cared -nn).  That way we're focusing on a layer3 problem.</div><div style><br></div><div style>I'd also suggest a list of what host has what IP address.  I don't know what </div><div><<a href="http://prometheus.avits.ca">prometheus.avits.ca</a>> address is or which it should be using (across the tunnel I'd expect RFC1918 like your other hosts).  I'm resolving prometheus' hostname to a public which isn't in that <a href="http://192.168.0.0/18">192.168.0.0/18</a> network.</div><div><br></div><div><div>~]$ dig -t A <a href="http://prometheus.avits.ca">prometheus.avits.ca</a> +short</div><div>184.71.26.174</div></div><div><br></div><div style># Interesting</div><div style># I suppose you may have DNS views that are coming into play here</div><div style># Another reason to leave out the DNS resolution on your packet captures :-)</div><div style><div>~]$ dig -t A <a href="http://db2.avits.ca">db2.avits.ca</a> +short</div><div>184.71.26.174</div><div><br></div><div style># Maybe it's time for a full diagram ... ASCII would do or Visio/Dia hosted on an image sharing site would suffice.</div></div><div><br></div><div style>While it would be helpful to see your OpenSwan config for this tunnel, it may not be necessary.</div><div style>I expect db2 is trying to connect to prometheus' public IP address.  Try excluding DNS from the equation by pinging from db2 to prometheus' address in the <a href="http://192.168.0.0/18">192.168.0.0/18</a> network.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If I need to provide a more detailed session, please let me know.<br></blockquote><div><br></div><div style>Since you're using SSH to remotely control those systems, you might use some other protocol/port to troubleshoot.  You said TCP doesn't work across the tunnel from <prometheus> to <db2>.  If there isn't some other TCP application, you might use netcat to do tests in either direction and this will allow you to filter your packet capture to that traffic easily.</div><div style><br></div><div style>* Start with determining if traffic is being generated with addresses that will match (your <a href="http://192.168.0.0/18">192.168.0.0/18</a> and <a href="http://192.168.64.0/18">192.168.64.0/18</a> networks) and be sent over the tunnel.</div><div style><br></div></div><div><br></div>-- <br><div class="gmail_signature">---~~.~~---<br>Mike<br>//  SilverTip257  //</div>
</div></div>