WAN + Bridged OPT Rules Problem since 1.2.x



  • Hello,

    Everything works fine with pfsense 1.2, but not under 1.2.x

    I have 4 nic's, my pfsense ip is xxx.xxx.xxx.130

    WAN (xxx.xxx.xxx.130/26, Gateway : xxx.xxx.xxx.129)
    |
    LAN (192.168.2.1/24)
    |
    OPT1 (bridged with WAN) (ip mail server : xxx.xxx.xxx.175)
    |
    OPT2 (LAN2, 192.168.1.1/24)

    If i upgrade from 1.2 to 1.2.x (i tried 1.2.2 & 1.2.3), i'm unable to send or receive mails with my server.

    My rules for WAN are:
    Source : xxx.xxx.xxx.175 Port : 25 |  Destination : *  *
    Source : xxx.xxx.xxx.175 *|  Destination : *  Port : 25
    Source : * Port : 25  |  Destination : xxx.xxx.xxx.175 *
    Source : * * |  Destination : xxx.xxx.xxx.175 Port : 25

    I have the same rules on the bridged interface (OPT1, bce1)

    Source : xxx.xxx.xxx.175 Port : 25 |  Destination : *  *
    Source : xxx.xxx.xxx.175 *|  Destination : *  Port : 25
    Source : * Port : 25  |  Destination : xxx.xxx.xxx.175 *
    Source : * * |  Destination : xxx.xxx.xxx.175 Port : 25

    Under Pfsense 1.2.2 or 1.2.3 on the syslog, i have

    pf: 80. 904615 rule 162/0(match): block in on bce1: (tos 0x0, ttl 64, id 32220, offset 0, flags [DF], proto TCP (6), length 60) xxx.xxx.xxx.17.25 > 2xx.x5.1xx.1xx.27272: [|tcp]

    @162 block drop in log quick all label "default deny rule"

    Rules that permit the smtp connection are not apply, i don't know why ?

    Thanks for your help



  • It may be just a typo but, quoting from the syslog entry, source xxx.xxx.xxx.17.25 destination 2xx.x5.1xx.1xx.27272 doesn't match any of your rules.

    Should the source be xxx.xxx.xxx.175 rather than xxx.xxx.xxx.17?

    Which interface is bce1?



  • Sorry it's a typo error on my post:

    pf: 80. 904615 rule 162/0(match): block in on bce1: (tos 0x0, ttl 64, id 32220, offset 0, flags [DF], proto TCP (6), length 60) xxx.xxx.xxx.175.25 > 2xx.x5.1xx.1xx.27272: [|tcp]

    Any idea for my prob ?



  • Which interface is bce1?



  • bce1 is OPT1
    OPT1 is bridged with WAN



  • Sorry I didn't notice that bce1 is OPT1 in the base note.

    Maybe you should dump all the rules to see why this packet is not matching your rules. The fact that the packet is not matching any rules before the "default deny all" rule suggests its not seeing the rules you have listed here.



  • Here my rules with pfctl -vvs rules

    /**************** WAN = em0 ********************/

    @95 pass in quick on em0 inet proto tcp from 2xx.xxx.xxx.x75 to any port = smtp keep state label "USER_RULE: WAN AMS SMTP OUT"
      [ Evaluations: 13296    Packets: 0        Bytes: 0          States: 0    ]
    @96 pass in quick on bridge0 inet proto tcp from 2xx.xxx.xxx.x75 to any port = smtp keep state label "USER_RULE: WAN AMS SMTP OUT"
      [ Evaluations: 8758      Packets: 0        Bytes: 0          States: 0    ]

    @97 pass in quick on em0 inet proto tcp from any port = smtp to 2xx.xxx.xxx.x75 keep state label "USER_RULE: WAN AMS SMTP IN 2"
      [ Evaluations: 13296    Packets: 0        Bytes: 0          States: 0    ]
    @98 pass in quick on bridge0 inet proto tcp from any port = smtp to 2xx.xxx.xxx.x75 keep state label "USER_RULE: WAN AMS SMTP IN 2"
      [ Evaluations: 8758      Packets: 0        Bytes: 0          States: 0    ]

    @99 pass in quick on em0 inet proto tcp from any to 2xx.xxx.xxx.x75 port = smtp keep state label "USER_RULE: WAN AMS SMTP IN"
      [ Evaluations: 13296    Packets: 278170    Bytes: 164963426  States: 319  ]
    @100 pass in quick on bridge0 inet proto tcp from any to 2xx.xxx.xxx.x75 port = smtp keep state label "USER_RULE: WAN AMS SMTP IN"
      [ Evaluations: 8758      Packets: 0        Bytes: 0          States: 0    ]

    /**************** OPT1= bce1 ********************/
    @177 pass in quick on bce1 inet proto tcp from 2xx.xxx.xxx.x75 to any port = smtp keep state label "USER_RULE: OPT1 STMP OUT"
      [ Evaluations: 1779      Packets: 34582    Bytes: 28737010    States: 2    ]
    @178 pass in quick on bridge0 inet proto tcp from 2xx.xxx.xxx.x75 to any port = smtp keep state label "USER_RULE: OPT1 STMP OUT"
      [ Evaluations: 1531      Packets: 0        Bytes: 0          States: 0    ]

    @179 pass in quick on bce1 inet proto tcp from 2xx.xxx.xxx.x75 port = smtp to any keep state label "USER_RULE: OPT1 STMP OUT"
      [ Evaluations: 1560      Packets: 86        Bytes: 4032        States: 0    ]
    @180 pass in quick on bridge0 inet proto tcp from 2xx.xxx.xxx.x75 port = smtp to any keep state label "USER_RULE: OPT1 STMP OUT"
      [ Evaluations: 1531      Packets: 0        Bytes: 0          States: 0    ]

    @181 pass in quick on bce1 inet proto tcp from any port = smtp to 2xx.xxx.xxx.x75 keep state label "USER_RULE: OPT1 STMP IN"
      [ Evaluations: 1561      Packets: 0        Bytes: 0          States: 0    ]
    @182 pass in quick on bridge0 inet proto tcp from any port = smtp to 2xx.xxx.xxx.x75 keep state label "USER_RULE: OPT1 STMP IN"
      [ Evaluations: 1531      Packets: 0        Bytes: 0          States: 0    ]

    @183 pass in quick on bce1 inet proto tcp from any to 2xx.xxx.xxx.x75 port = smtp keep state label "USER_RULE: OPT1 STMP IN 2"
      [ Evaluations: 1584      Packets: 0        Bytes: 0          States: 0    ]
    @184 pass in quick on bridge0 inet proto tcp from any to 2xx.xxx.xxx.x75 port = smtp keep state label "USER_RULE: OPT1 STMP IN 2"
      [ Evaluations: 1531      Packets: 0        Bytes: 0          States: 0    ]



  • Assuming you haven't changed the rules since the block syslog entry was created, the challenge is to find out why the logged packet hit rule 162 before it hit your set of rules for bce1. (My understanding is that the rules are effectively checked in order.) Clearly some packets matched to rules 177 and 179.

    That some traffic apparently matched rules 99, 177 and 179 suggests there must be some SMTP traffic getting through. You haven't made full disclosure of the rules and the exact IP addresses and masks so its difficult to give you an explanation of what you are observing.

    Your number of rules will make this tedious, but I suggest that without changing the firewall rules you do what ever it is you need to do to get the "block" syslog entry, dump the firewall rules as you have done and then work through them to see why the blocked packet was blocked. Once you know that it might be clearer why the packet in question is getting blocked. (Perhaps typo in an IP address or mask.)

    Looking again at your firewall rules, I'm not sure how any reader would be able to determine whether or not the destination address in the blocked packet (2xx.x5.1xx.1xx) should match the destination address in the third rule (xxx.xxx.xxx.175). I would guess that it didn't.



  • Thank you for your reply, but the question is why with pfsense 1.2 everything works fine and not with 1.2.x
    If it is a problem with my rules under pfsense 1.2 i should have the same issue, no ?



  • @MadX:

    Thank you for your reply, but the question is why with pfsense 1.2 everything works fine and not with 1.2.x

    I'm not a pfSense developer. I expect a developer would have to answer that question.

    @MadX:

    If it is a problem with my rules under pfsense 1.2 i should have the same issue, no ?

    I can give you an example of another change in behaviour of bridged interfaces that occurred somewhere in the transition from 1.2 to 1.2.1 (or maybe 1.2.2). In 1.2 if DHCP was enabled on the LAN interface and the LAN interface was bridged with a wireless interface then DHCP was also enabled on the wireless interface. The pfSense developers considered that a bug and quietly changed things so that to get DHCP working on the bridged wireless interface it became necessary to add firewall rules to pass DHCP traffic on the wireless interface.

    pfSense includes software that translates from the firewall rules specified through the web GUI to the pf rules you have been displaying. The FreeBSD pf.conf man page gives details of the pf rule syntax. I expect the pfSense developers would consider they have the right and responsibility to change that translation, especially to correct "bugs". Sometimes when that translation changes new bugs are introduced. A further factor to consider is that the FreeBSD developers may also discover "bugs" in the kernel pf and kernel pf may also have changed in a transition from FreeBSD 6.x to FreeBSD 7.1.



  • @MadX:

    Thank you for your reply, but the question is why with pfsense 1.2 everything works fine and not with 1.2.x
    If it is a problem with my rules under pfsense 1.2 i should have the same issue, no ?

    Same here.
    Rule 161 is evaluated but there is explicit allow all and doesn't matter what I change it is still the same.
    I have bridge between VLAN (DMZ) and WAN, all Intel PRO cards.
    What is your MBUF usage?

    Feb 11 21:26:56 172.16.84.254 pf: 11. 319782 rule 161/0(match): block in on vlan9: (tos 0x0, ttl 64, id 31210, offset 0, flags [DF], proto TCP (6), length 60) 161.53.202.120.80 > 66.249.72.200.50182: S, cksum 0xdcbd (correct), 1991400661:1991400661(0) ack 1545673196 win 5792


Locked