Problem with TCP and GRE tunnel
-
@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 -
-
Hmm, same both ways?
Try using one of the other IPs on the server as the target. The GRE endpoint IP can behave in an odd way.
-
@stephenw10 I tried but or give me firewall problem because the port isnt exposed or give me that
-
Which way are you testing? The server end should listen on all available IPs by default. I would expect the client end to have a route to any of them.
-
@stephenw10 Im starting the server on the VPC (from the company where i bought the IP's and VPC) and client on the local pf VM
-
Ok so you should be able to use the VPC WAN address as the target for the client.
-
-
Aha, and that could be the problem. That IP is in the same /24 as the local LAN side clients. If you have those set to a /24 subnet it will try to ARP for it directly and fail.
-
@stephenw10 Uh, im very noob with this sorry, what exacly i need to change?
