SOLVED: multiple LAN subnets with routers between them, no internet for remote s



  • All,

    I have a network where there are two buildings, and each building has it's own subnet, ie:

    192.9.200.0/24 is building 1
    192.9.201.0/24 is building 2

    (Don't judge me on the subnets, I inherited them!)

    Between the two subnets is a Cisco 1800 router.
    Traffic routes freely between the subnets.
    It has an IP on both subnets, which happens to be 192.9.200.1 and 192.9.201.1.
    It's everyone's default gateway. Users on the 200 network use 200.1 as their gateway. Users from 201 network use 201.1 as their gateway.
    In the Cisco 1800 is a static route that says "ip route 0.0.0.0 0.0.0.0 192.9.200.250", so all internet traffic is forwarded to the pfSense firewall, at 192.9.200.250.

    I just replaced their Cisco ASA5505 firewall with a pfSense 2.0 firewall.

    The issue is, everyone on the 192.9.200.0 network can access the internet just fine.
    Everyone on the 192.9.201.0 network cannot. Before switching them off of the Cisco ASA5505, everything worked fine.

    Originally I thought this was a static route issue in pfSense. I went to System -> Routing -> Gateways and defined the following gateway rule:

    Name Interface Gateway Monitor IP Description
    Bldg2Net LAN 192.9.200.1 192.9.201.230 Cisco 1800 series router in Bldg 2 Cabling Closet

    Then I went to System -> Routing -> Routes and defined the following route:

    Network Gateway Interface Description
    192.9.201.0/24 Bldg2Net - 192.9.200.1 LAN Bldg2 Net

    It didn't solve the problem.

    Then I suspected the packet filter wasn't allowing the traffic through. Off I go to Firewall -> Rules -> LAN and I define the following two rules:

    ID Proto Source Port Destination Port Gateway Queue Schedule Description

    • bldg2net * * * * none   Default allow Bldg2Net to any rule
        • bldg2net * * none   Default allow any to Bldg2Net rule

    Nada. Still won't route.

    Then I tried under WAN rules, just to be thorough:

    ID Proto Source Port Destination Port Gateway Queue Schedule Description

    • bldg2net * * * * none
        • bldg2net * * none

    Nope. Nothing.

    I can ping from the firewall shell to the server in Building 2:

    PING 192.9.201.230 (192.9.201.230): 56 data bytes
    64 bytes from 192.9.201.230: icmp_seq=0 ttl=127 time=0.563 ms
    64 bytes from 192.9.201.230: icmp_seq=1 ttl=127 time=0.751 ms
    64 bytes from 192.9.201.230: icmp_seq=2 ttl=127 time=0.539 ms
    64 bytes from 192.9.201.230: icmp_seq=3 ttl=127 time=0.534 ms
    64 bytes from 192.9.201.230: icmp_seq=4 ttl=127 time=0.750 ms

    … and I can ping from the Cisco 1800 router to both the server and the pfSense firewall:

    ping 192.9.201.230
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.9.201.230, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

    ping 192.9.200.250
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.9.200.250, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

    If I start a packet capture while attempting to ping a website from the Building 2 Server, I see packets captured on the firewall:

    15:08:55.919810 IP 192.9.201.230.52833 > 96.11.72.150.443: tcp 0
    15:08:58.912020 IP 192.9.201.230.52833 > 96.11.72.150.443: tcp 0
    15:09:04.909981 IP 192.9.201.230.52833 > 96.11.72.150.443: tcp 0

    Perhaps it's frustration talking, but I'm at a loss. Any ideas what I'm missing?



  • @anomaly0617:

    All,

    Perhaps it's frustration talking, but I'm at a loss. Any ideas what I'm missing?

    Solved it. It took talking to another BSD nerd to figure it out.

    The problem was under Interfaces -> WAN.

    Uncheck this: Block private networks. When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8).  You should generally leave this option turned on, unless your WAN network lies in such a private address space, too.

    Then traffic will be permitted to return to the 192.9.201.0 network.


Log in to reply