Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    WAN + Bridged OPT Rules Problem since 1.2.x

    Scheduled Pinned Locked Moved
    1.2.3-PRERELEASE-TESTING snapshots - RETIRED
    3
    11
    8.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      MadX
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        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?

        1 Reply Last reply Reply Quote 0
        • M
          MadX
          last edited by

          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 ?

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            Which interface is bce1?

            1 Reply Last reply Reply Quote 0
            • M
              MadX
              last edited by

              bce1 is OPT1
              OPT1 is bridged with WAN

              1 Reply Last reply Reply Quote 0
              • W
                wallabybob
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • M
                  MadX
                  last edited by

                  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    ]

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallabybob
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • M
                      MadX
                      last edited by

                      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 ?

                      1 Reply Last reply Reply Quote 0
                      • W
                        wallabybob
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • S
                          ssbaksa
                          last edited by

                          @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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.