Bug in NAT

  • 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.


    default gateway:

    openvpn client:
    remote 1194

    WAN1: nat on vtnet1 inet from to any -> port 1024:65535
    WAN2: nat on vtnet2 inet from to any -> port 1024:65535

    With this config everything works as expected.

    default            UGS        0  458751 vtnet1

    vtnet1 udp ->      MULTIPLE:MULTIPLE

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

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

    default            UGS        0  459349 vtnet1

    vtnet1 udp -> ->      MULTIPLE:MULTIPLE

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

    default            UGS        0  459863 vtnet2

    vtnet2 udp -> ->      MULTIPLE:MULTIPLE

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

    openvpn client:

    default            UGS        0  460562 vtnet2

    vtnet2 udp -> ->      MULTIPLE:MULTIPLE

  • 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.

  • 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?

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

  • 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)?

  • 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.

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

  • 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.

  • now I made it manually with floating rules:
    pass out route-to (vtnet1 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 ->

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

  • Rebel Alliance Developer Netgate

    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.

  • 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.

Log in to reply