Bug in NAT

ggzengel

There is a bug in NAT in FeeeBSD.
If a source IP in a NAT rule match an external interface IP the packet goes the default route and hops over the interfaces.
It doesn't matter in which sequence the NAT rules are. They goes to the default route.

config:
WAN1: 10.2.1.10/24
WAN2: 10.2.2.10/24
LAN: 10.19.3.222/24

default gateway: 10.2.1.1

openvpn client:
local 10.2.2.10
remote 10.1.1.10 1194

NAT:
WAN1: nat on vtnet1 inet from 10.19.3.0/24 to any -> 10.2.1.10 port 1024:65535
WAN2: nat on vtnet2 inet from 10.19.3.0/24 to any -> 10.2.2.10 port 1024:65535

With this config everything works as expected.

route:
default 10.2.1.1 UGS 0 458751 vtnet1

state:
vtnet1 udp 10.2.2.10:22632 -> 10.1.1.10:1194 MULTIPLE:MULTIPLE

But if I change NAT to:
nat on vtnet1 inet all -> 10.2.1.10 port 1024:65535
nat on vtnet2 inet all -> 10.2.2.10 port 1024:65535

The packet goes over wrong interface:
It jumps from WAN1 to WAN2

route:
default 10.2.1.1 UGS 0 459349 vtnet1

state:
vtnet1 udp 10.2.2.10:49809 -> 10.2.1.10:30761 -> 10.1.1.10:1194 MULTIPLE:MULTIPLE

If I change default gateway to WAN2 the packet goes the right way to WAN2

route:
default 10.2.2.1 UGS 0 459863 vtnet2

state:
vtnet2 udp 10.2.2.10:28599 -> 10.2.2.10:18612 -> 10.1.1.10:1194 MULTIPLE:MULTIPLE

If I change the openvpn setting to WAN1 the packet goes the wrong way.

openvpn client:
local 10.2.1.10

route:
default 10.2.2.1 UGS 0 460562 vtnet2

state:
vtnet2 udp 10.2.1.10:58728 -> 10.2.2.10:54346 -> 10.1.1.10:1194 MULTIPLE:MULTIPLE

ggzengel

After I posted this in this structured form I see that packet goes a strange way.
1. The packets goes the routing rule. In my case the default rule.
2. The packets get NAT rules.
3. The packet goes to the interface which source ip match.

Here is the problem:
In GUI I give openvpn an interface and think it goes really over this interface. But in real the NAT rule for the interface with the default gateway will match.
The user won't see this problem.

podilarius

There is not a bug in the NAT. I think there is a flaw in the thinking on what it should be doing. The way you describe it is the way it looks like it should be working. I think what you are looking for is a MultiWAN setup with makes use of gateway groups. What are you trying to accomplish?

cmb

There's no such bug. My guess is you're breaking reply-to via floating rules or interface groups or have it disabled.

ggzengel

Yes it's not a bug. I wrote it in the second post.
It's the difference between the operating systems I know and the way pfsense will route packets.
I'm used that NAT rules comes at least (after the decision which interface will be used) and can not hop over the interfaces.

1. The interface in the openvpn config is not really the interface the packets will go. It will only set the source IP of the packets.
2. NAT is done befor the interface is choosen. The source IP address after NAT will choose the outgoing interface.
3. The router itself (if no other routes) will use the NAT of the default route and not the interface you choose in openvpn.
4. If the default route changes the NAT rule for openvpn changes too, even if it's using the same outgoing interface.

@cmb: Your guess is wrong. It was the outgoing NAT rule. That's the problem I will show. If openvpn configured to WAN1 and you have a default route to WAN2 the NAT rule for WAN2 will be used for openvpn. I expect (for right) that NAT rule for WAN1 will be used.

Isn't it possible to make a rule in pf which says if a packet goes to dest:1194 alway go to WAN1 (and use NAT rule for WAN1)?

podilarius

You can. It is called policy routing. This is only true for traffic originating from the LAN or the localhost (of pfSense). Basically you create a rule that matches the traffic specifically, as in the destination port, and tell it to use a particular gateway. Since order matters, this rule would need to be above any default rules. Again, this is covered in multiWAN setups.

ggzengel

I'm speaking about user friendly:
If I choose WAN1 in openvpn use NAT rule for WAN1. The pf rules should made automatically.

podilarius

I did a quick search on multiwan and openvpn, and it looks to have been covered several time. Start there and then update this topic from there.

ggzengel

now I made it manually with floating rules:
pass out route-to (vtnet1 10.2.1.1) inet proto udp from any to <alias_pfsense1_1>port = 1194 keep state label "USER_RULE"

But it didn't take the right NAT rule. It still use NAT of vtnet2.
vtnet2 udp 10.2.1.10:29861 -> 10.1.1.10:1194

If this is really not working with pfsense then please change the text in openvpn config:
Interface -> IP from Interface</alias_pfsense1_1>

jimp

Are you talking about the client traffic or the traffic for the VPN tunnel itself?

If you have OpenVPN set to "any" interface, then UDP traffic replies will always go out via the system's default route. That's how UDP works, the UDP daemon replies from the IP address on the system "closest" to the client, which is typically the default route. It doesn't even consider NAT or pf in any of those cases. Floating rules with route-to can help some but it still relies on the default route to pick the source address for UDP.

To work around that, bind the VPN to a specific interface and not 'any', or use a port forward to forward the traffic from that WAN's IP to localhost or any other interface IP, and the replies will be sourced properly.

ggzengel

My intention is not to config a pfsense.
My intention is to make the GUI clear for other users.

I speak about the crypted packets of openvpn client.

Assuming the default route is on interface WAN2.
If you config an interface (WAN1) for an openvpn client the pfsense will never take the rules (NAT or filter) for this interface (WAN1).
But the GUI will let you think that the rules for WAN1 will be choosen.

If you have OpenVPN set to "any" interface, then UDP traffic replies will always go out via the system's default route.

I'm not speaking about replies.
It doesn't matter which interface you set for openvpn client, the UDP/TCP traffic will always go out via the system's default route.
It always uses the rules (NAT, filter) of the default route interface and not the interface which is set for the openvpn client.
After this the outgoing interface will be choosen by the source ip address of the packet.

It's not clear for somebody that the rules of an other interface, than the configured, are the right one.