On 09/08/2011 04:30 AM, Marco wrote:
2011/9/8 Kevin VPN<[email protected]>:
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?
_______________________________________________
vpn-help mailing list
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help
