Problem with TCP and GRE tunnel
-
Ok, if the IPs are purchased from the VPC then they are presumably routed to the public IP there. So that should avoid any asymmetric routing.
So I would run a pcap on the WAN interface at the VPC end and see what's happening there for an ICMP and TCP connection.
-
@stephenw10
There's the pcap -> (WAN) on the VPC with "ping google.com" and "curl ifconfig.me"
-
stephenw10 Netgate Administratorlast edited by stephenw10 Mar 31, 2024, 6:29 PM Mar 31, 2024, 6:28 PM
Can you upload the actual pcap file here? https://nc.netgate.com/nextcloud/s/BynTbfz33wrToAm
I assume the curl fails?
-
@stephenw10 I'll do it in a sec, no the curl works but with a lot of delay
-
@stephenw10 Uploaded the pcap from VPC, WAN while doing a curl ifconfig.me
-
Hmm, weird there's a 30s gap between the initial syn/ack handshake and the http get request.
Does that same delay appear at local pf in a pcap there? It seems unlikely it would actually just wait which implies the initial request is being lost. Perhaps an MTU issue?
Is there any reason you chose to use GRE for this instead of something encrypted?
-
@stephenw10 Do you want a pcap on the local pf? If yes which interface? GRE?
An there's no reason to chose GRE, I just heard about it and decided to give it a try. -
The pcap should be identical on the local GRE and LAN interfaces. If it isn't that's probably where the problem is.
GRE has a few quirks that OpenVPN or route-mode IPSec do not. Since you're not NATing or encrypting though you shouldn't be hitting any of them.
-
@stephenw10 I think they are but maybe i miss something, do you want me to upload the pcap on the same URL?
-
Yes please.
-
@stephenw10 Done
-
Ok well the delay is a lot longer there but you can see the local host sends the http request almost immediately after the handshake. So packets are being lost somewhere.
Try running pcaps on both ends of the GRE tunnel at the same time. Run the curl command and see how they compare.
-
@stephenw10 Just upload them. Also how can I open the pcap files to compare them?
-
Using Wireshark is easiest. Though you can also just set the view to high or full in the pfSense webgui and see the timing info etc.
-
@stephenw10 But are you able to see any difference between them now?
-
Yes, you can see the local end sees the initial http request at 0.02 but no reply. It retransmits that request 10 times until it finally sees a reply at 114s.
At the remote end it never sees any requests arrive until 114s.
Something is dropping those packets in the route. They are not large packets so not an MTU issue that might be caused by encapsulation.
I assume you gateways setup for the GRE tunnel, do you see packet loss logged on them?
Just to confirm; are you using encryption here? GRE over IPSe transport?
-
@stephenw10 On both sides pf say 0.0% packet loss while using curl. Also no, im not using encryption or GRE over IPSe
-
Hmm. What happens if you run curl against the webgui at the remote side?
Or try running an iperf test between the two pf instances.
-
Also try running a pcap on the WAN interface of the local pf when running that same curl test. You should not see any traffic leaving there directly other than the GRE encapsulated traffic.
-
@stephenw10 I already tried to see the traffic on WAN (local pf) and theres no traffic. I will try the other 2 things give me a sec