[Openswan Users] Tunnel up, some hosts work, others don't.

[SilverTip257]

On Wed, Feb 25, 2015 at 1:19 PM, Richard Whittaker <richard at avits.ca> wrote:

> On 2015-02-25 09:57, SilverTip257 wrote:
>
> Here's some captures from one of my "near" hosts to one of the non working
> "far" hosts...
>
>
Those packet captures appear to indicate no problems.  Established TCP
session and so forth.

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.

I'd also suggest a list of what host has what IP address.  I don't know
what
<prometheus.avits.ca> 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 192.168.0.0/18 network.

~]$ dig -t A prometheus.avits.ca +short
184.71.26.174

# Interesting
# I suppose you may have DNS views that are coming into play here
# Another reason to leave out the DNS resolution on your packet captures :-)
~]$ dig -t A db2.avits.ca +short
184.71.26.174

# Maybe it's time for a full diagram ... ASCII would do or Visio/Dia hosted
on an image sharing site would suffice.

While it would be helpful to see your OpenSwan config for this tunnel, it
may not be necessary.
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 192.168.0.0/18 network.


> If I need to provide a more detailed session, please let me know.
>

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.

* Start with determining if traffic is being generated with addresses that
will match (your 192.168.0.0/18 and 192.168.64.0/18 networks) and be sent
over the tunnel.


-- 
---~~.~~---
Mike
//  SilverTip257  //
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150226/15ca1347/attachment.html>