I've gotten so far as to see that yes, the DST is receiving PINGs and sending REPLYs.
Definitely no firewall involved. The SRC tcpdump also shows the replies coming in on eth0, but they don't seem to make it up the stack to be counted. I haven't brought it into Wireshark yet, though, hopefully later today. As to the GP client itself, I'm actually not sure what lay beneath the covers there. -----Original Message----- From: David Woodhouse [mailto:[email protected]] Sent: Monday, April 8, 2019 4:49 PM To: Phillips, Tony Cc: Nikos Mavrogiannopoulos; Daniel Lenski; [email protected] Subject: Re: [EXTERNAL] Re: What throughput is reasonable? On Mon, 2019-04-08 at 21:42 +0000, Phillips, Tony wrote: > Hrrrm… No dice here. > > Summary: Getting some RNETLINK barking and "policy FAIL" on the > serer side, but ESP connection does seem to connect. > > But no traffic flowing through it. The "clients" tun0 interface > does show OUTPUT packets, but nothing seems to be coming back from > the other end? > > See detailed output from both sides below -- I've probably missed > something. Make sure neither side has a firewall blocking UDP packets. Do a tcpdump on the public interface at both ends, as each tries to ping the other. Capture those UDP frames, tell wireshark how to decode them (you have the keys). If the "server" end isn't receiving packets... are you sure you're running esplisten.pl ? Note you can also run the script at both ends and have kernel to kernel ESP, before you reset the client end and try OpenConnect instead. Another random thought... are you sure the proprietary client was actually using ESP in the first place? If it was communicating over the TCP connection using a modern version of TLS and an AEAD cipher it could well have been going a lot faster than ESP ever will when limited to AES-CBC. _______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
