GRE Tunnel using Proxy ARP

[stephenw10]

@Xuap said in GRE Tunnel using Proxy ARP:

If I traceroute an IP like cloudflare's warp, it goes through the tunnel, but if it's from the inner network of the remote pfsense, like 185.113.141.4 or the dns server 185.113.141.253, it doesn't go through.

Where are those IPs? They are not in the list you gave. If those are targets it will fail because they are inside the local LAN subnet. Which is all kinds of wrong.

If you don't have the proxy ARP VIPs does it stop working entirely?

Can I assume this is the actual same issue as this thread:
https://forum.netgate.com/topic/187069/problem-with-tcp-and-gre-tunnel

Steve

[Xuap]

@stephenw10 Hey stephen, so, answering your questions:

Where are those IPs? They are not in the list you gave. If those are targets it will fail because they are inside the local LAN subnet. Which is all kinds of wrong.

The 185.113.141.4 is a random server on the inner network of the 185.113.141.1 remote gateway, that the network admin said we could try to traceroute.

The 185.113.141.253 is the DNS server of the remote network (Redirects to 8.8.8.8 afaik).

If you don't have the proxy ARP VIPs does it stop working entirely?

I removed the 185.113.141.145/32 IP from the VIPs in the remote pfsense and the network still goes the same. I can ping 1.1.1.1, curl some http host but still the same, not working for https.

Can I assume this is the actual same issue as this thread:
https://forum.netgate.com/topic/187069/problem-with-tcp-and-gre-tunnel

StomperG is a colleague of mine and is on the same boat with me on this one. I'm a little more experienced with pfsense since I've been using it for a year or so, therefore he asked me to make a topic about the matter and since I know what is working or not I can safely explain it to you.

(His topic can be closed if you want)

---

Any idea what can be done to force the local IP to go through the 185.113.141.145?

Best regards.
Xuap

[stephenw10]

The basic problem here is that you're trying to use something that is expected to be in the same layer 2 but route it across a layer 3 tunnel.

So the two solutions would be to either make it routed properly as I suggested in the other thread. Or to switch to a completely layer 2 setup using something like OpenVPN TAP mode and bridges.

You said you tried to add the gateway as outside the subnet and it didn't work?

[Xuap]

@stephenw10 How would it work by making it go over a complete layer 2 using OpenVPN in TAP mode?

Yes, it basically considers the gateway as non-local but doesn't work.

We've tried using Wireguard before but it just went deprecated, so any idea on the OpenVPN? I would need to close the GRE tunnels and make everything go through the vpn?

Best regards

[stephenw10]

Wireguard is not deprecated but it is layer 3. It won't help here.

To use OpenVPN create the tunnel with both ends configured in TAP mode. Then bridge the remote end to the WAN and the local end to the LAN. The local LAN will then be in the same layer 2 segment as the VPC side WAN so devices will see each other and everything will use the VPC side gateway directly. The local LAN could use one of the available IPs you have or have no IP address if the local pfSense does not require access to the subnet directly.

https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-bridged.html

[Xuap]

@stephenw10 Ok, so if I'm getting this right, my local pfsense should connect to the OpenVPN as a TAP client and get the openvpn interface assigned to the lan 185.113.141.0/24 network?

[stephenw10]

It doesn't matter which end is client but I would probably choose the local end, yes.

The OpenVPN interface is not assigned as LAN. You have to bridge it to the LAN by creating a bridge and adding both LAN and OpenVPN to it. At the other end it's bridged to the WAN.

How much latency is there between the pfSense instances? High latency across a layer 2 link can cause problems.

[Xuap]

@stephenw10 Whenever I start the OpenVPN interface, after a few seconds it just stops my connection to pfsense, any idea why?

The latency is 9ms. It always worked fine, without any issues...

[Xuap]

@Xuap Just forget the part where it stops my connection. It was lacking the port 80 pass rule loool

[Xuap]

@Xuap Ok.. so I tried creating the tunnel as follows:

Remote

---

Local

---

Local pfsense rules:

Remote pfsense rules:

Any error here?

Because the status is just that it don't connect...

[Xuap]

@stephenw10 Any idea?

[TwentyTwo]

@Xuap I tried the same setup as you and got the same problem.

[stephenw10]

Sorry missed the replies here.

It looks like you're using the webgui cert as the server cert? It has to be a cert created against the server CA.

It also looks like the TLS key is different. Both ends must have the sane TLS key.

You also still have a bunch of routed tunnel settings like pushing routes and adding gateways. But I'd fix up the cert/key first before looking at that.

Steve