[Openswan Users] IPsec-Setup

Thu Apr 14 23:01:31 EDT 2011

Maybe this applies...
A time or two during my testing when I would remove or update a "conn"
for some reason a routing table entry _seemed_ to remain.  I haven't
had this type of behavior since I created a proper configuration.

During that time period I simply removed the routing table entries
with the `route (add|del)` command or `ip route (add|del)`.  Openswan
added the necessary entries when I brought the tunnel up again.

However if the systems are establishing the connection for the first
time, then there shouldn't be any remnant routing table entries.
My suggestion would be for Thomas to check his routing table.
`route -n` -OR- `ip route show`

---~~.~~---
Mike
//  SilverTip257  //

On Thu, Apr 14, 2011 at 16:31, Willie Gillespie
<wgillespie+openswan at es2eng.com> wrote:
> On 4/14/2011 6:56 AM, Thomas Schweikle wrote:
>> Am 13.04.2011 16:42, schrieb Willie Gillespie:
>>> On 04/13/2011 07:02 AM, Thomas Schweikle wrote:
>>> I haven't tested it, but I imagine a line like this should cover it:
>>> tcpdump -i eth0 icmp or esp or tcp port 500 or tcp port 4500
>
> Looks like I had a typo here, where I should have put "udp" instead of
> "tcp".  Didn't matter for our tests here, but I figured I should correct
> myself.
>
>> local gateway (192.168.1.4):
>> # tcpdump -i eth0 icmp or esp or tcp port 500 or tcp port 4500
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 14:50:38.190171 IP 192.168.1.98>  192.168.180.30: ICMP echo request,
>> id 27142, seq 1, length 64
>> 14:50:39.198767 IP 192.168.1.98>  192.168.180.30: ICMP echo request,
>> id 27142, seq 2, length 64
>>
>> remote gateway (192.168.180.27):
>> # tcpdump -i eth0 icmp or esp or tcp port 500 or tcp port 4500
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>
> So not even the encrypted packets are showing up on the remote end here.
>
>
>> Gateway/Gateway:
>> local (192.168.1.4):
>> # tcpdump -i eth0 icmp or esp or tcp port 500 or tcp port 4500>  dump2
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> ^C8 packets captured
>> 10 packets received by filter
>> 0 packets dropped by kernel
>> # cat dump2
>> 14:55:07.086106 IP 192.168.1.4>  192.168.1.208: ICMP echo request,
>> id 56337, seq 0, length 28
>> 14:55:08.526408 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 1, length 64
>> 14:55:09.527758 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 2, length 64
>> 14:55:10.532153 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 3, length 64
>> 14:55:11.532148 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 4, length 64
>> 14:55:12.532158 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 5, length 64
>> 14:55:13.532164 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 6, length 64
>> 14:55:14.533895 IP 192.168.180.27>  192.168.1.4: ICMP echo reply, id
>> 2308, seq 7, length 64
>
> It gets the replies here, but I still don't see any ESP packets.
>
>>
>> remote (192.168.180.27):
>> # tcpdump -i eth0 icmp or esp or tcp port 500 or tcp port 4500>  dump2
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> ^C8 packets captured
>> 8 packets received by filter
>> 0 packets dropped by kernel
>> # cat dump2
>> 14:55:02.799942 IP 79.229.126.102>  213.95.82.27: ICMP host
>> 79.229.126.102 unreachable, length 252
>> 14:55:08.504997 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 1, length 64
>> 14:55:09.506554 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 2, length 64
>> 14:55:10.510107 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 3, length 64
>> 14:55:11.509762 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 4, length 64
>> 14:55:12.510303 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 5, length 64
>> 14:55:13.510585 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 6, length 64
>> 14:55:14.512651 IP 192.168.1.4>  vpn-gw.xompu.de: ICMP echo request,
>> id 2308, seq 7, length 64
>
> It's getting the echo requests directly from 192.168.1.4, which is good
> and what you want except for I still don't see an ESP packets.  It looks
> to me that while these two hosts are communicating, they are not doing
> so inside of the IPsec tunnel and instead just directly routing packets
> somehow.
>
> Anybody know why this could occur?
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>