Issue with 172.n.n.n networks (Private Addy Space)

  • I am running pfs 2.0-release on an ALIX2d3 embedded system. I am using the three physical interfaces as follows:

    Untrust - WAN: ISP with DHCP
    DMZ - Static Address Assignment for DMZ devices
    Trust - LAN networks - trunk - multiple VLANs

    On the Trust side I have 6 VLANs configured.

    Four of the VLANs are in the address space 10.n.n.n/24

    One of the VLANs is in the address space 172.16.n.n/24

    The final VLAN is in the address space of 172.30.n.n/24

    All the VLANs pass traffic correctly except the one in address space 172.30

    I have spent considerable amounts of time looking at why this is. The firewall rules are fine. No messages in the logs to indicate any issue.

    As a last ditch effort in testing I re-ip'd the interface to and a workstation to It works! Traffic passes. As soon as I return the configuration to and the workstation to the traffic flow stops. Packet sniffing shows traffic outbound, nothing returning inbound. Nothing odd about routes (no static routes defined).

    I then tried some different network address combinations - such as and None of them work. It only passes if I use 172.16.n.n

    Has anyone else seen this??

    RFC1918 defines the following as a private address space range:      -  (172.16/12 prefix)

    Technically I should not have an issue with 172.30.

  • I use  here.  site one.  site two…  ect...

    no issues...

    Ill try 172.30. on my test box later if no one else comments...

  • Presumably you have a VLAN capable switch in the configuration. What is its IP address? Hopefully not

    If duplicate IP addresses don't seem to be the problem I would examine a simplified configuration: pings between pfSense and workstation. Does a ping from pfSense to the workstation get a response? Does a ping from the workstation to pfSense get a response? Does a packet capture on pfSense show both request and response? Does a packet capture on the workstation show request and response?

  • Hi guys. Thanks for the replies. After stepping away for a while and coming back I made a discovery. I ran packet traces on both the trust and untrust side. On the untrust I immediately noticed something. The address was being seen on the outside. I jumped back into my NAT settings and noticed I "fat-fingered" an ip address.

    I can't tell you how many times I checked these settings, but apparently I glossed over it repeatedly. Sorry about that. Thanks again for the replies!

Log in to reply