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

    Static routing problem

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 2 Posters 1.9k 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.
    • C
      conehead
      last edited by

      Hi,

      I never used static routing before and have a problem to get everything working.

      Current situation:

      2 routers (1 pfsense for backup internet and wireless acces), a cisco router for connection with other location (leased line).

      Current setup:

      pfsense: one wan, 1 lan (10.0.10.254) and one opt with 2 vlans (50: wireless personeel and 60: wireless guests) (dhcp enabled on pfsense).

      when i connect to wireless guest en and wireless personeel i am getting the expected range of ip adresses (192.168.50.? or 192.168.60.? ) and i can surf the internet.

      My problem:

      I want my clients on vlan 50 also make a connection to the 10.0.0.0 netwerk thats where the cisco router comes in to play: has an ip adress of 10.0.10.253 and 200.0.0.253) and forwards everything to the 10.0.0.0 network.

      what dit i do:

      under gateways i created another gateway: 10.0.10.253
      and under roots i added the root: 10.0.0.0/23 to 10.0.10.253

      result:

      in pfsense i can now ping from the lan interface a pc or server in the 10.0.0.0 range which is good.

      but from my vlan 50 on pfsense i can ping only the 10.0.10.253 address but no host behind it ??

      So what am i missing to ping a host from the vlan 50 in the 10.0.0.0 network ?  (no vpn is used: it's one local network)

      thanks in advance

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

        The Cisco router has direct connection to both 10.0.0.0/23 and 10.0.10.0/24 (which has pfSense on it). So it can easily route between these without needing any extra static route. That is why you can ping from pfSense or the 10.0.10.0/24 network.
        The Cisco will know nothing about 192.168.50.0/24 - so it will not be able to send reply packets back to that network. Add a route on the Cisco to 192.168.50.0/24 through the pfSense gateway 10.0.10.254.
        And make sure you have firewall rules on Cisco and pfSense that allow the traffic to pass.

        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
        • C
          conehead
          last edited by

          Hi,

          I was thinking something like that but i have nog username and password for the cisco device … was placed by an external party ... will need to contact them than.

          thanks for the reply

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

            If you just want connections that start from 192.168.50.0/24 and access things in 10.0.0.0/23 then you should be able to add a manual out bound NAT entry to pfSense on LAN, for source 192.168.50.0/24, destination 10.0.0.0/23, translation address = interface address. Then flows from 192.168.0.0/24 will get changed to come from 10.0.10.254 - the Cisco knows how to route back to that, and pfSense can "unNAT" the returning packets and deliver them.
            (Devices on the Cisco will not be able to access things in 192.168.50.0/24 - but I don't think that is a requirement for you)

            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
            • C
              conehead
              last edited by

              that is indeed not a requirement

              thanks for the help

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