Hi Tjago, is the problem fixed, what was it?
Greetings, Eike Am 26.08.2015 um 12:18 schrieb Jan Just Keijser: > Tiago Vasconcelos wrote: >> 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. >> >> > does this router have netcat of socat ? if so, run it in listening mode > (e.g. nc -l -p 12000) and see if you can connect to that. > alternatively, what happens if you run a (second) ssh instance on a port > other than 22 ? can you connect to that port? > The question that I would like to see answered is: are TCP connection > between the VPN client and the server possible at all. Perhaps it's a > faulty ssh daemon or they've built in that ssh access is not allowed > over anything but eth0 . > > HTH, > > JJK > > > ------------------------------------------------------------------------------ > _______________________________________________ > Openvpn-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openvpn-users ------------------------------------------------------------------------------ _______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
