PROBLEM (see detailed CONFIGURATION INFO near bottom of posting):
Disabling interfaces on pfSense can cause permanent loss of ability to
connect to webConfigurator. Here's what's happening:
- I have a second/testing pfSense box configured almost identically to
the production one (only 6 ports instead of 7 and only the 4-port Sun
card is the same brand of NIC). When I try to "clone" the production
configuration onto the test system, I do the following (detailed
CONFIGURATION INFO near bottom of posting):
- edit the port names for the 2 interfaces/NICs that are different (e.g.,
sk0 -> dc0, etc.) and remove the "blocks" related to the 6th/opt5 WAN
port (i.e., <opt5>...</opt5>,
<rule>...<interface>opt5</interface>...</rule>, etc.)
- boot the test box and load the cloned/edited production config ... note
that only the LAN and WAN have cables attached
- with WANs 2 through 4 "down" (no cables attached), I am unable to
connect to pfSense's webConfigurator (even after restarting both the
webConfigurator or rebooting pfSense) -- 'Though I can't access the
webConfigurator, I can still log in via ssh
- it seems like there's same kind of routing issue ... here's what I see:
* ifconfig shows (dc0 is LAN):
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet 172.16.10.1 netmask 0xffffff00 broadcast 172.16.10.255
inet6 ...
ether 00:00:94:ec:59:eb
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
hme0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_MTU>
inet 24.207.77.100 netmask 0xfffffc00 broadcast 24.207.79.255
inet6 ...
ether 00:03:93:98:d6:d6
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
* netstat -r shows
(verrry slooowly ... like there's some kind of network timeout for each
entry)
Internet:
Destination Gateway Flags Refs Use Netif Expire
0 link#6 UC 0 0 de0 =>
default 24.207.76.1 UGS 0 146 hme0
24.207.76/22 link#2 UC 0 0 hme0
24.207.76.1 00:ef:90:27:9f:7d UHLW 2 50 hme0 1191
24.207.77.100 localhost UGHS 0 0 lo0
localhost localhost UH 1 0 lo0
172.16.10/24 link#1 UC 0 0 dc0
gateway 00:00:94:ec:59:eb UHLW 2 0 lo0
172.16.10.5 link#1 UHLW 1 9 dc0
172.16.10.98 00:17:e2:c3:5a:06 UHLW 1 0 dc0 454
172.16.10.104 00:17:e2:c3:5a:06 UHLW 1 0 dc0 447
172.16.10.105 00:17:e2:c3:5a:06 UHLW 1 0 dc0 440
172.16.10.106 00:17:e2:c3:5a:06 UHLW 1 0 dc0 433
172.16.10.107 00:17:e2:c3:5a:06 UHLW 1 0 dc0 426
172.16.10.109 00:17:e2:c3:5a:06 UHLW 1 0 dc0 419
172.16.10.220 link#1 UHLW 1 78 dc0
172.16.10.233 00:17:ee:c3:5a:06 UHLW 1 272 dc0 406
Note that neither 172.16.10.5 nor 172.16.10.220 are IP addresses of any
device on
the test network so I have no idea where these came from. 172.16.10.233
is the IP of the laptop being used for testing and it has
172.16.10.98/104/105/106/107/109 IP aliases. There is only a
single/direct cable between a laptop and the LAN/dc0 interface
and a single/direct cable between the WAN interface and a cable modem so
there were no other systems on the network.
It's also interesting that the non-connected hme1-3 interfaces each show
an ifconfig of
"no carrier" but the non-connected de0 interface shows an ifconfig of
"active" and
gets an IP of 0.0.0.0 (and appears in the routing table, unlike the
hme1-3 interfaces)
Here are some other things I see while pfSense is in this mode:
from fpSense's shell:
---
any ping to a FDQN gets
ping: cannot resolve <the-name>: Host name lookup failure
... makes sense 'cause DNS is set incorrectly for test network
ping to an Internet/WAN-accessible IP works
---
from laptop on LAN, ping to 172.16.10.1 (pfSense's LAN) works
from laptop on LAN, ssh connection to 172.16.10.1 (pfSense's LAN) works
from laptop on LAN, attempts to HTTP to 172.16.10.1 (pfSense's LAN) don't
work
---
Safari can't open the page "http://172.16.10.1/";. The error was:
"Operation could not be completed. (kCFErrorDomainCFNetwork error 302.)"
curl: (52) Empty reply from server
---
What's strange is that pftop shows, for each attempted HTTP connection,
an entry like:
tcp Out 172.16.10.1:55385 172.16.10.5:80 SYN_SENT:CLOSED
tcp Out 172.16.10.1:14473 172.16.10.5:80 SYN_SENT:CLOSED
My interpretation is that pfSense is trying to route its own incoming
172.16.10.1/LAN out to 172.16.10.5 ... which isn't even on the network.
Why it'd be trying to do this, I can't figure out.
In the "cloned" config:
... there are NAT rules related to 172.16.10.5:
(looking at web interface)
"port forward NAT" WAN2 TCP HTTP 172.16.10.5 HTTP
"manual outbound NAT" WAN2 172.16.10.5/32 * * * * * NO
... and firewall rules related to 172.16.10.5:
(looking at web interface)
LAN: * 172.16.10.5 * * * WAN2
WAN2: TCP * * 172.16.10.5 HTTP *
There's also a firewall LAN rule (after the 172.16.10.5 rule)
(looking at web interface)
* 172.16.10.0/24 * * * *
- I also saw (what appears to be) the same kind of behavior on the
production pfSense when I disabled (by unchecking Interfaces -> WAN# ->
Enable Optional <#-1> interface) WANs 6 through 3 (leaving only the LAN,
WAN and WAN2 interfaces)
- once a pfSense has gotten into this mode, the only way I've found to
restore it is to reset to factory defaults then load the last-saved
config (thank goodness for this nice capability!)
I know this is a lot of "stuff" ... but I'm completely baffled, on this
one. Help <please>?
CONFIGURATION INFO:
- pfSense 1.2 Config with 5 WANs: see screenshots at
http://www.derman.com/Misc/router/pfSense.html
- 5 static IPs from DSL assigned via DHCP via 1 device (WANS -> switch ->
DSL modem) where each static IP corresponds to a separate domain
- 2 of the static IPs are on 1 subnet and 3 are on a different subnet ...
this means that the WANs use only 2 next-hop routers at the ISP for all 5
WANs so "...suppress ARP messages when interfaces share the same physical
network" is checked
- IPs 172.16.10.4-5-6-7-22 are all on 1 server/1 NIC (1 IP + 4 alias IPs)
and the web server's vhost config is based upon the 172.16.10.4-5-6-7 IPs
--
-----------------------------------------------
Bryan Derman Derman Enterprises Incorporated
http://www.derman.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
