I've been on this for the better part of the day. Everything seems fine, and really behaves as such (well, except it's not working), but there must be a catch somewhere.
The server:
- NetgearVPN server
- wan: dynamic ip
- lan: 10.0.0.0/24
- ip: 10.0.0.1
The client:
- shrew VPN client (tried different versions)
- lan: 172.16.0.0/16 (gw:172.16.0.4)
- ip: 172.16.0.59
The VPN brings up a tap0 interface (ip range 10.1.0.0/24), the tunnel is established, no problem there. Remote hosts can ping and ssh the client on it's virtual ip (10.1.0.1). However, the client can't seem to access anything.
Once set up, route -n looks as such:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.0.4 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 10.1.0.1 255.255.255.0 UG 0 0 0 tap0
10.1.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Couldn't be better. The only type of activity (ping, in this case) I see on tap0 interface is this:
tcpdump -i tap0 -n -X -s0:
16:42:03.494457 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001 .;..........
16:42:04.491415 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001 .;..........
16:42:05.491419 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001 .;..........
16:42:06.508946 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001
The fact the ARP request response on IP 172.16.0.59 confuses me.
When remote hosts access the client, tap0 activity remains empty.
So, I'm asking, where could the catch be ? Client-Host incompatibility ? wrong configuration ? Bug in client software ? A firewall somewhere (where ?) ? Where else could I look for logs & information on what is going on ?
Solved it: /etc/rc.local still had some nat related iptables rules in effect, blocking the vpn interface
Strange because iptables -L didn't show anything at run-time.
These were the incriminating rules:
After trying out the shrew client on windows & other debians everything went well, so I went to look what was wrong on the current one. Did cost me days though.