What does the routing table look like? The fact that you can ping makes this seem unlikely, but other than that it sounds like it *might* be getting dropped by urpf. (that's the only place I can think of between where libpcap would see it but a listening socket wouldn't, other than iptables which you've already covered.)
-Joe On Tue, Aug 25, 2015 at 10:01 AM Tiago Vasconcelos < [email protected]> wrote: > Hi Gert > > On 25-08-2015 13:20, Gert Doering wrote: > > If it pings, it should SSH. If it doesn't, someone is firewalling > > you (INPUT chain, not FORWARD) > > I also thought so. Which makes this case a mystery to me. > Here's why: > > > # SSH is indeed running on the OpenVPN server > > $ netstat -ln | grep 22 > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN > > > # No firewall rules on the server side... > > $ iptables-save > # Generated by iptables-save v1.4.3.2 on Tue Aug 25 14:34:07 2015 > *nat > :PREROUTING ACCEPT [9:777] > :POSTROUTING ACCEPT [19:1364] > :OUTPUT ACCEPT [19:1364] > COMMIT > # Completed on Tue Aug 25 14:34:07 2015 > # Generated by iptables-save v1.4.3.2 on Tue Aug 25 14:34:07 2015 > *mangle > :PREROUTING ACCEPT [925:77105] > :INPUT ACCEPT [924:77005] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [599:67933] > :POSTROUTING ACCEPT [599:67933] > COMMIT > # Completed on Tue Aug 25 14:34:07 2015 > # Generated by iptables-save v1.4.3.2 on Tue Aug 25 14:34:07 2015 > *filter > :INPUT ACCEPT [843:70905] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [599:67933] > COMMIT > > > # Server capture while running 'telnet 192.168.1.2 22' on the client > # As can be seen, the SYN is not responded and the client keeps retrying > > $ tcpdump -i tun0 -n > 14:30:41.389162 IP 172.31.0.6.60902 > 192.168.1.2.22: Flags [S], seq > 3893675608, win 4350, options [mss 1130,sackOK,TS val 6434347 ecr > 0,nop,wscale 1], length 0 > 14:30:44.338170 IP 172.31.0.6.60902 > 192.168.1.2.22: Flags [S], seq > 3893675608, win 4350, options [mss 1130,sackOK,TS val 6437347 ecr > 0,nop,wscale 1], length 0 > > > # Doing a strace on the SSH daemon (Dropbear) confirms it doesn't > # receive any connection attempt > > $ strace -p 218 > Process 218 attached > select(8, [4], NULL, NULL, NULL > > > # 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 > > > I ran out of ideas... > Maybe there's something fishy with this router's firmware (renewed > Oleg's firmware https://code.google.com/p/wl500g/). Both endpoints are > actually Asus routers running the same firmware and OpenVPN versions. > > > Thanks, > Tiago > > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
