[vpn-help] Give access to more than one machine?

[Marco]

(Sorry for sending the previous mail to you privately)

2011/9/9 Kevin VPN <kvpn at live.com>:

>> ...
>> What I see is always the same, see the following tcpdump snippets. The
>> first was taken from the remote machine (192.168.1.12), the second
>> from the local machine running the VPN client. This is while trying to
>> ping 192.168.1.12 (a remote machine behind the remote VPN gateway)
>> from 10.4.0.18 (a machine in the local LAN, to which of course I had
>> previously added the route to 192.168.1.0/24 via the Shrew VPN
>> machine):
>>
>> # while doing "ping -c 1 192.168.1.12" on 10.4.0.18
>>
>> ...
>>
>> # this looks OK - 192.168.10.219 is the Shrew VPN client's address on
>> tap0, assigned upon connection, so masquerading worked
>>
>> # and the following is on the Shrew VPN box - don't mind the
>> timestamps, they're slightly off:
>>
>> # tcpdump -v -n -i any icmp
>> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
>> size 96 bytes
>> 10:17:27.655119 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
>> ICMP (1), length 84) 10.0.4.18>  192.168.1.12: ICMP echo request, id
>> 10028, seq 1, length 64
>> 10:17:27.698583 IP (tos 0x48, ttl 57, id 46349, offset 0, flags
>> [none], proto ICMP (1), length 84) 192.168.1.12>  192.168.10.219: ICMP
>> echo reply, id 10028, seq 1, length 64
>>
>
> Hi Marco,
>
> There is something odd about the second packet in tcpdump on the Shrew VPN
> box. My expectation is that tcpdump should not know that a packet from the
> VPN gateway to the Shrew client address is an ICMP packet. It's supposed to
> be encrypted in a tunnel.
>
> The first packet in the tcpdump is the inbound ICMP from the other host on
> the local subnet.  Hence the source address of 10.0.4.18 and ICMP type.  The
> second packet is from the VPN gateway to the Shrew client address and it is
> also identified as ICMP.  I would expect all traffic from the gateway to the
> Shrew client to be identified as IKE/ISAKMP/IP50/UDP500 traffic (or
> something like that) and hence would not show up.  That's why there's no
> ICMP packet outbound from the Shrew client IP to the gateway in your dump.
>
> My thought on this is that the return packet from the gateway network is not
> coming back through the tunnel.  Is this possible given your setup?

Note that there I was capturing only ICMP traffic. If I change the
capture filter to include UDP port 4500, the encrypted packets do show
up (10.0.4.100 is the Shrew box's LAN address, x.x.x.x is the remote
VPN concentrator):

shrewbox# tcpdump -v -n -i any icmp or udp port 4500
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 96 bytes
10:31:02.142694 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84) 10.0.4.18 > 192.168.1.12: ICMP echo request, id
14367, seq 1, length 64
10:31:02.142816 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 144) 10.0.4.100.4500 > x.x.x.x.4500: UDP-encap:
ESP(spi=0x0953125a,seq=0x85b), length 116
10:31:02.173169 IP (tos 0x0, ttl 55, id 53038, offset 0, flags [none],
proto UDP (17), length 144) x.x.x.x.4500 > 10.0.4.100.4500: UDP-encap:
ESP(spi=0x0de90eeb,seq=0x8a2), length 116
10:31:02.173194 IP (tos 0x48, ttl 57, id 3004, offset 0, flags [none],
proto ICMP (1), length 84) 192.168.1.12 > 192.168.10.219: ICMP echo
reply, id 14367, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Also capturing at the LAN gateway shows ESP in UDP packets flowing in
both directions, so I would say that things are fine.

Furthermore, Shrew IPsec has its own set of oddities in the way
(cleartext) traffic shows up in tcpdump, for more information see this
post: http://lists.shrew.net/pipermail/vpn-help/2011-April/003658.html.

But regardless, I am confident that the encryption process is working
correctly; the problem is that it seems that Shrew somehow prevents
Linux from successfully doing stateful tracking of the connection,
because (and that is may original problem) the ICMP reply packet never
gets back to 10.0.4.18; it seems it's dropped by the Shrew box.
Note that it's also possible that I'm not using the correct iptables
rule to do it (I based it on what I did on an OpenSwan machine, where
the same thing did work fine); what I've tried is

iptables -t nat -A POSTROUTING -d 192.168.1.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.0.4.0/24 -d 192.168.1.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tap0 -d 192.168.1.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE

none of these work. If this is the problem, suggestions are of course
welcome. Thanks!