Project

General

Profile

Actions

Bug #6524

closed

192.168.100.0/24 subnet with Cable Modem WAN un-workable

Added by Xander Venterus almost 8 years ago. Updated almost 8 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
-
Start date:
06/22/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:
amd64

Description

So here is the scenario i ran into today.

Customer Subnet is 192.168.100.1/24
Customer WAN IP is 174.77.55.XX6/28
Customer GW IP is 174.77.55.XX5

If the cable modem on the WAN side is of a model which has a status/diagnostics page on an ip of 192.168.100.1 as the following models do: Motorola, Scientific Atlanta, Cisco, and numerous others, The WAN becomes completely un-usable in this situation, occasionally a packet or two goes through, but 99% of the traffic is returned by the gateway with Destination Host Unreachable.

The only solution was to re-IP the whole customer network to 192.168.10.1/24 which took me an hour plus to do. This used to work on older versions as some time back i used a simular set of subnetting on a different site with an older 2.2.X build of pfsense.

I noticed on the console while watching PFsenses WAN interface attempt to DHCP when i removed the static IP, it was getting random IPs in the 192.168.100.0/24 range, but it would release the ip almost in the same second as it would get it.

This also caused a condition where the PHP-FPM would hangup or such and i wouldnt be able to get to the web admin, or it would lag really really bad, and restarting the FPM resolved that whenever it happenned.

I know that its unlikely to ever encounter such a scenario but it might behoove to note this behavior and advise against using such a subnet, or else fix the cause of this erroneous behavior.

This was tested on the latest 2.3.1 P5 firmware as of todays date.

Actions #1

Updated by Chris Buechler almost 8 years ago

  • Status changed from New to Not a Bug
  • Affected Version deleted (2.3.1)

it's workable just fine. You can't have the same subnet on two diff interfaces of any firewall/router. You have some kind of problem there, but it's not a bug nor anything software can do anything about. Start a forum post and people can offer suggestions.

Actions

Also available in: Atom PDF