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

All trafic with changed gateway

Scheduled Pinned Locked Moved Firewalling
5 Posts 3 Posters 1.5k Views
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
    martijnr17
    last edited by Aug 27, 2013, 9:29 AM

    I'm using pfsense now for a few days.
    I've a multiple wan interfaces en lan interfaces.

    I've made a group WanGroep with the 2 wan interfaces. There is a firewall rule that allows NTP traffic from wlan to * with the gateway wangroep instead of the default gateway.
    As soon as I change the gateway to wangroep instead of default all tcp trafic is allowed from wlan to anywhere on any port instead of the allowed port.

    pfsense1.png
    pfsense1.png_thumb

    1 Reply Last reply Reply Quote 0
    • P
      phil.davis
      last edited by Aug 31, 2013, 11:26 AM Aug 31, 2013, 10:59 AM

      When I add a rule like that, on a 2.1-RC1 system, /tmp/rules.debug gets this added:

      pass  in  quick  on $LAN1 inet proto tcp  from any  to <negate_networks> flags S/SA keep state  label "NEGATE_ROUTE: Negate policy routing for destination"
      pass  in  quick  on $LAN1  $GWNTPGWG inet proto tcp  from any to any port 123 flags S/SA keep state  label "USER_RULE: Test NTP"</negate_networks>
      

      <negate_networks>is a list of networks I have defined in OpenVPN. I guess the code tries to protect those OpenVPN-defined networks (whose routes are already "fixed" on OpenVPN connections) from being re-routed by a policy-based rule into a gateway group that may not go somewhere successful.
      The problem I see is that the first rule does not specify "port 123" - so it opens up access for all ports from $LAN1 to <negate_networks>(the OpenVPN-reachable stuff).
      Seems like a bug, that first rule should have a "port" spec in it the same as the 2nd rule?

      Edit: I added an issue in RedMine: http://redmine.pfsense.org/issues/3173</negate_networks></negate_networks>

      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
      • M
        martijnr17
        last edited by Sep 2, 2013, 12:02 PM

        Thank you, good to hear that it is a bug. I was already getting crazy.

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by Sep 3, 2013, 6:46 PM

          This should be fixed on latest snapshots.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by Sep 4, 2013, 1:43 AM

            The changes to filter.inc did not make:
            2.1-RC1 (i386)
            built on Tue Sep 3 14:08:44 EDT 2013

            They will appear in the snapshot after the above.
            I copied the new /etc/inc/filter.inc manually, and it is working. Sample test rule output from /tmp/rules.debug :

            pass  in  quick  on $LAN inet proto tcp  from 10.49.80.99  to <negate_networks>  port 123 flags S/SA keep state  label "NEGATE_ROUTE: Negate policy routing for destination"
            pass  in  quick  on $LAN  $GWWiMax_Priority inet proto tcp  from 10.49.80.99 to any port 123 flags S/SA keep state  label "USER_RULE: Testing only zzzz"</negate_networks>
            

            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
            3 out of 5
            • First post
              3/5
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
              This community forum collects and processes your personal information.
              consent.not_received