Problem with TCP and GRE tunnel
-
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
-
The other thing to test would be a pcap on both WANs at the same time so you can check if GRE packets are leaving the local WAN and just not arriving at the remote WAN. I.E. is it an actual problem in the route somewhere.
-
@stephenw10 I can curl without problems on the remote one. Also how can i do a iperf?
-
@stephenw10 I did it now and theres no logs on the local side (WAN) while doing a pcap
-
iperf is a package you can install in the gui. You can also install just the backend pkg at the command line if you want.
@StomperG said in Problem with TCP and GRE tunnel:
I did it now and theres no logs on the local side (WAN) while doing a pcap
So the local side isn't actually sending GRE packets even though the pcap on the GRE interface shows them?
-
@stephenw10 At least the WAN pcap on the local dont show anything
-
Nothing at all? It must show the GRE packets if the curl command succeeds. Or do you mean just during the unexpected delay?
-
Hi
maybe this will help
I don't remember why I set up the rules this way (I think I read it in some article), but
1 GRE interface (MSS 1380)
2 created this floating rule for GRE interface (TUN100)
here is an example of the information transfer rate through a tunnel with these settings
-
That can be required for GRE+IPSec transport. Although there is now an option to allow it without that: https://redmine.pfsense.org/issues/12289
However in that situation the initial handshake would fail. And that shouldn't apply here because it's not encrypted. But....anything's possible!
-
@stephenw10 Hey that's for the local or remote pf? I tried on local and had the same result :/
-
@stephenw10 Nothing at all on the local WAN
Never did an iperf, is there any topic for that? -
Yeah I wouldn't expect it to make any difference there because you're not using IPSec transport.
To my earlier question; do you really see no GRE packets in the pcap on the local WAN? Or just during the gap?
-
At the command line on each end you can run
iperf3. So runiperf3 -sto start a server at one end. Theniperf3 -c <server IP>at the other. -
@stephenw10 On the local WAN i literally see 0 lines of logs during de pcap
-
@stephenw10 I just need to run this 2 commands and wait? Or did i need to do something else on the VM with the problem? And the server IP is the GRE IP right?
-
Hmm, are you filtering the pcap on the local pf?
Yes the server side runs continually until you kill it. The client will run for 30s by default.
https://man.freebsd.org/cgi/man.cgi?query=iperf3
