Problem with TCP and GRE tunnel
-
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?
-
Ok we're back to how the VPC is providing the IPs to you. You have 4 consecutive IPs at the local pf LAN? Including the pf LAN interface address?
The VPC pf WAN address is not consecutive to those?
You probably need to device those into to subnets so routing works correctly.
The routing table at the local pf cannot include the remote side WAN address.
The remote side must be using a smaller subnet than /24 because otherwise connectivity would be completely broken.
