Hi Gert
On 25-08-2015 21:07, Gert Doering wrote:
> Where is 172.31.0.6 routed to? If the linux side of things doesn't
> route this address into the tun interface, it might be the rp_filter
> eating the SYN ACK, or you're just not seeing the SYN ACK as it's
> sent out to the default router...
Traffic from the server towards 172.31.0.6 gets routed via tun0:
$ ip ro ge to 172.31.0.6
172.31.0.6 via 172.31.0.2 dev tun0 src 172.31.0.1
cache mtu 1490 advmss 1450 hoplimit 64
I can even ping 172.31.0.6 from the server:
$ ping 172.31.0.6
PING 172.31.0.6 (172.31.0.6): 56 data bytes
64 bytes from 172.31.0.6: seq=0 ttl=64 time=187.558 ms
>> # Strangely, pings from the client do work!
>>
>> $ ping 192.168.1.2
>> PING 192.168.1.2 (192.168.1.2): 56 data bytes
>> 64 bytes from 192.168.1.2: seq=0 ttl=64 time=105.582 ms
>> 64 bytes from 192.168.1.2: seq=1 ttl=64 time=103.611 m
>
> Is it using the same IP addresse for the ping source (check with
> tcpdump)?
Yes, it is.
Here's a tcpdump (taken on the server side) of the 'ping 192.168.1.2':
$ tcpdump -i tun0 -n
22:58:08.653553 IP 172.31.0.6 > 192.168.1.2: ICMP echo request, id
24585, seq 11, length 64
22:58:08.653860 IP 192.168.1.2 > 172.31.0.6: ICMP echo reply, id 24585,
seq 11, length 64
And here's a tcpdump of the 'telnet 192.168.1.2 22':
$ tcpdump -i tun0 -n
23:00:49.002409 IP 172.31.0.6.43183 > 192.168.1.2.22: Flags [S], seq
1292589374, win 4350, options [mss 1114,sackOK,TS val 9876830 ecr
0,nop,wscale 1], length 0
23:00:52.116802 IP 172.31.0.6.43183 > 192.168.1.2.22: Flags [S], seq
1292589374, win 4350, options [mss 1114,sackOK,TS val 9879830 ecr
0,nop,wscale 1], length 0
Same source IP in both cases.
A mystery.
Thanks,
Tiago
------------------------------------------------------------------------------
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
