PfSense 2.1 seems not to obey to a rule with a different gateway



  • I've a pfSense with a LAN and a DMZ nics.
    This pfSense is "internal", I mean it is not directly connected to Internet: it uses a default gateway specified on the LAN nic.

    THE PROBLEM:
    traffic originating from machines on the DMZ should be directed to another gateway (not the default one), which is used for all the VPN's.
    To doing so I've set up a rule on the DMZ nic, telling pfSense that all traffic from DMZ to a particular network should be managed by another specified gateway.

    BUT the pfSense continues to send the packets to the standard default gateway, instead of sending them to the other gateway.

    I'm suspecting it could be a bug…..
    Thanks



  • FWIW: Works fine here (v2.1), and I have a whole bunch of rules (floating & if bound) using policy based routing & various gateways.

    My best guess given your information:
    The traffic of interest does not hit your rule? If you switch on logging for that rule, can you see the traffic 'hits' it?
    If it is a floating rule: Try switching the direction of the rule… (by default I think it is 'out', and in most of my cases it was 'in'  :))
    Question: did you add manual routes to the DMZ subnet? If it has a direct route, it bypasses the rules... (or so I seem to remember)



  • My ping results are as follows:

    • from LAN to server: no answer
    • from server to LAN: OK

    I can reach the server from the Lan ONLY IF I remove the default gateway on the LAN nic of the remote pfSense (the internal one, with the DMZ nic on which lives my server).

    I can think it's a problem of paths, I mean: from Lan to server the packets pass through a path but from server to Lan the packets are using a different path.



  • hmm, I didn't understood you needed connectivity originated from both ways.
    You have on both interfaces a policy based rule then?



  • I have just one policy based rule: the one on DMZ interface.

    The behaviour is (for me..) very strange, infact:

    1. if I ping from my LAN  to the server I receive no answer BUT the server IS RECEIVING MY PING (I know because I've enabled iptables logging on the server)
    2. if I ping from the server to the LAN everything is ok (also without the policy based rule)
    3. If I remove the default gateway on the pfSense DMZ interface I can ping without problems from my LAN


  • Thinking on 2 things now (this troubleshooting in the dark isn't that easy  ::)): NAT or the default block.

    How is your Oubound NAT configured? Default? Reason I ask is that when it is automatic, it uses the NAT rules (table) except when it is a WAN type connection (and I think that is what it becomes when you define a Default Gateway)
    You might need to switch to manual NAT.

    Also, on a WAN type connection, there is no allow in and everything gets dropped silently. (unless you configure it otherwise, but I wouldn't recommend that as it can pollute logs heavily)
    Try defining a rule at the end of your DMZ list, drop any any with logging. then repeat your ping test. If the icmp reply is sent back to the correct IP (lan address from where you sent it), you should see it in the logs.



  • The MANUAL Nat managemet is enabled: I've disabled NAT from DMZ subnet to LAN subnet.

    I'm starting to figure out how to remove the default gateway from the NIC interface, leaving to the machines attached to pfSense (attached to NIC and DMZ and using it as the default gateway) the ability to connect to Internet.



  • That shouldn't be too hard. You can always add a static route in pfSense to your internet gateway…?
    Don't know though if there's a catch, never done that (my pfSense's all have at least one WAN interface connected).
    Keep us posted here, it's always good to learn  ;)


Log in to reply