VPN and NAT Reflexion

[dennis_u]

Hello.

(network diagram is attached)

Due to limited public IPs, we use Port Forwarding from outside to inside. The NAT points in most cases to some servers in the DMZ. Let's assume, we have an URL like app.acme.com, which resolves to our public IP 1.2.3.4 . You can access https://app.acme.com from the internet as expected. In order to reach app.acme.com also from inside, the OPNsense does NAT Reflection. This works also fine (you can see blue RDR rules in the log).

But: it doesn't matter, if you use OpenVPN or Wireguard, Road Worriors can not access https://app.acme.com. If they disable VPN, they can use it immediately. But then, they cannot access pure internal applications anymore. Rules and routing are double and triple checked.

It is no routing issue, since I am able to follow the traces, if you access the Reverse Proxy directly. One work around may be that app.acme.com is resolved direct to the Proxy instead of the public IP. But we have also a general purpose DNS name and the OPNsense decides which destination is the right one based on the port.

In general, why is it a problem to do NAT reflexion and through a VPN tunnel? Or is there a tick I missed to set? There are already some related topics here in the board, but they are in most cases unanswered and damn old. I would like to investigate this.

[Monviech (Cedrik)]

A secret technique is to put the reverse proxy on the OPNsense itself which will cut out all the NAT issues just like that.

There are quite a few to choose from.

[dennis_u]

A secret technique is to put the reverse proxy on the OPNsense itself which will cut out all the NAT issues just like that.

There are quite a few to choose from.

To be honest, I am not a fan of such an architectural approach. Furthermore, it is not good security practice to do all tests on one system.
With a reverse proxy in a DMZ I can filter and analyze the incoming traffic to the RP, the outgoing traffic from the RP AND the content in the RP.

* - replace RP with any other kind of application gateway like DNS, MTA, etc.

It is good to know for smaller installation (SOHO) that you do not have to install an entire data center, but use some features with OPNsense. In general, it should be avoided, if it is possible.


BUT, this is not the question: why is this kind of traffic not possible?

[Monviech (Cedrik)]

Essentially that traffic should be possible.

I once wrote a full tutorial for this:

https://docs.opnsense.org/manual/how-tos/nat_reflection.html

Have you found out where exactly on the request and reply packet's path it gets lost or routed unexpectedly?
Does one of the SNAT or DNAT rules not match as expected?
Best use ICMP for a baseline.

[dennis_u]

The first SYN packet never arrives the server. If I do not make a logical mistake, there is no RDR entry for source=VPN dest=1.2.3.4, but there are entries from internal clients.

Is the RDR rule not bound to VPN interfaces? Where is it defined?

[Monviech (Cedrik)]

You can check your pf ruleset with:

pfctl -s nat

And check there if the rdr rule would match if the traffic comes from the VPN interface (ovpnX or wgX)

Also, some constellations with VPN interfaces also need reply-to tweaking:

https://github.com/opnsense/docs/blob/e46dfd4cb78dd2459716785a4ca46950e70b8a92/source/manual/how-tos/nat_reflection.rst?plain=1#L116-L117

Essentially following this section in the linked guide should give you most infos to solve this:

https://github.com/opnsense/docs/blob/e46dfd4cb78dd2459716785a4ca46950e70b8a92/source/manual/how-tos/nat_reflection.rst?plain=1#L82

https://docs.opnsense.org/manual/how-tos/nat_reflection.html#method-1-creating-manual-port-forward-nat-dnat-manual-outbound-nat-snat-and-automatic-firewall-rules

I know its a tough read but this NAT stuff is pretty annoying.