Stateless rule not matching



  • I am trying to reproduce an application problem by simulating dropped packets on a faulty network using pfSense 1.2.3.

    Specifically, I need to build a TCP connection between a client (10.1.2.8 on LAN) and server (10.1.4.4 on OPT1), send data in a PSH/ACK to the server, and drop the returning ACK.
    Since I can manipulate the timing of the data being transmit to the server, I was trying to accomplish this with a pair of stateless rules.

    Rule on LAN interface:
    Allow source 10.1.2.8 port any, destination 10.1.4.4 port 1090, state type: none

    Rule on OPT1 interface
    Allow source 10.1.4.4 port 1090, destination 10.1.2.8 port any, state type: none

    The idea was to allow the connection to be built between client and server and then disable the OPT1 rule before transmitting data from the client so that the PSH/ACK will pass through but the return ACK will be dropped by the default deny rule.

    The trouble I'm having with this configuration, is that with both the rules in place, the connection cannot be built. The SYN from the client is passed to the server, but the SYN/ACK from the server is dropped by the default deny rule on the LAN interface (which doesn't make sense as it should only have to match a rule on the OPT1 interface).

    I upgraded the pfSense from 1.2.3 to the latest 2.0 beta and tried again. Same problem, but there's an additional info when checking the rule that triggered the action:

    pass Jan 16 01:03:35 LAN 10.1.2.8:10181 10.1.4.4:1090 TCP:S
    block Jan 16 01:03:35 LAN 10.1.4.4:1090 10.1.2.8:10181 TCP:SA
    The rule that triggered this action is:
    @2 scrub in on fxp0_vlan4 all fragment reassemble
    @2 block drop out log all label "Default deny rule"

    With pfSense 1.2.3 the message is simply
    @2 block drop out log all label "Default deny rule"

    I tried to apply the second rule to the LAN interface to catch the SYN/ACK on the LAN interface before the default deny rule got it but it doesn't change anything.

    Any thoughts why this might be happening? The MTU on all machines involved is 1500, which is plenty large enough to prevent fragmentation at this point in the connection setup.
    I can provide my config backup or tcpdump / wireshark traces upon request.



  • The 'pass out' rules that keep state will still apply when you do that. The only way you can get around that is manually hacking and loading your /tmp/rules.debug to also have 'no state' on 'pass out'. Given it's likely a temporary need, just do manual edits, don't touch anything in the GUI and you'll be fine to do your testing.



  • Thank you, adding a "pass out" rule manually then removing it successfully accomplished what I was trying to do.


Locked