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

[Kevin VPN]

On 09/08/2011 04:30 AM, Marco wrote:
> 2011/9/8 Kevin VPN<kvpn at live.com>:
>> On 09/04/2011 07:52 AM, Marco wrote:
>>> I'm aware that IPsec is peculiar in how traffic flows, but is it the
>>> case that this would break iptables' NAT too?
>>>
>>
>> I'd suggest first seeing if you can make this work without the complication
>> of the VM virtual networking.  See if you can have another physical box on
>> your LAN send traffic via your host box that is destined for the remote LAN.
>>   That will tell you if the concept works.  My guess is that it should be
>> possible.
>
 >
> ...
> 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?