Navigation

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

    'Limiter' rules bug when upgrading to latest 2.1-BETA0 snap

    2.1 Snapshot Feedback and Problems - RETIRED
    3
    4
    1817
    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.
    • D
      dhatz last edited by

      TEMPORARY SOLUTION: DISABLE ANY RULES USING LIMITERS (h/t phil.davis) or don't upgrade to latest 2.1-BETA0 snaps until the issue is resolved

      This is a very quick heads up that since upgrading to latest beta snap, I seem to have connectivity problems.

      pfSense version:
      FreeBSD fw.localdomain 8.3-RELEASE-p4 FreeBSD 8.3-RELEASE-p4 #1: Fri Oct 12 10:10:48 EDT 2012     root@snapshots-8_3-i386.builders.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8  i386

      config.xml is basically the same I've been running for the past year.

      I haven't yet had the time to troubleshoot the issue, but it seems that systems behind pfsense's NAT are unable to reach IPs in subnets that aren't directly connected (they can reach IPs in WAN subnet).

      E.g. outbound ssh from hosts in LANnet (outbound NAT is set to automatic) won't work, except to hosts in WANnet

      • packets aren't blocked
        tcpdump on pflog0 doesn't show anything blocked

      • attempt to ssh to remote host fails:
        tcpdump -i em1 (LAN if) port 22 shows the ssh packet coming in, but no traffic on em0 (WAN if)

      • attempt to ssh to a host in WANnet subnet works
        tcpdump prints the relevant traffic both on em1 and em0

      • the pfsense box itself connects fine to anyone (ssh, telnet to port 80 etc)

      • checking states with pfctl -ss

      all tcp xxx.yyy.z.4:22 <- 192.168.100.12:3725       ESTABLISHED:ESTABLISHED
      all tcp 192.168.100.12:3725 -> xxx.yyy.z.201:26443 -> xxx.yyy.z.4:22       ESTABLISHED:ESTABLISHED
      all tcp xxx.yyy.z.3:22 <- 192.168.100.12:3768       ESTABLISHED:ESTABLISHED
      all tcp 192.168.100.12:3768 -> xxx.yyy.z.201:31952 -> xxx.yyy.z.3:22       ESTABLISHED:ESTABLISHED
      all tcp aa.bb.40.155:22 <- 192.168.100.12:3841       CLOSED:SYN_SENT

      xxx.yyy.z.0/24 is WANnet
      aa.bb.40.155 any other remote host

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis last edited by

        If you have any rules with limiters, it is broken. I have put 1 pull request for a small interface bug, which has been sitting there for a day now without any action or comment on it. But it really needs someone (the originator of the commit that broke it?) to urgently fix this or revert it.
        Disable any rules with limiters and routing/filtering should come back to life.
        See http://forum.pfsense.org/index.php/topic,54595.0.html
        Notice to all: If you use limiters then DO NOT update to current snapshot until this problem is fixed.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • D
          dhatz last edited by

          phil.davis thanks, it was indeed due to 'Limiters'

          (note: in my setup the "WAN net" was excluded from the Limiter rule which had a Destination ! xxx.yyy.z.0/24 )

          After disabling that single Limiter rule, everything seems to be back to normal.

          1 Reply Last reply Reply Quote 0
          • O
            orion last edited by

            I can also confirm the limiter bug in the snap, disabling the limiter clears the issue.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post