Weird setup issue
-
We were unable to ping both the ISP gateway and Google's DNS from the webConfigurator.
When the Win7 box was put in place of pfSense, both of the above were pingable.
-
I assume you are using 2.0.3 32bit? Some people have had some odd IPv6 routing issues recently with 2.1RC.
Other than that I out of suggestions. :( Other than contacting Negate who may have some insight specific to your ISP. I'm the wrong side of the pond for that. ;)
Steve
-
Perhaps this is something more fundamental. The Netgate box has be proven when you configured it initially (assuming it wasn't damaged in transit). The EoC box has been proven by connecting the Win7 box.
The interface reports being UP but is it really? So far you have seen no traffic at all from vr1, yes?
This is the sort of thing that can be caused by some rare hardware mismatch. Is the Netgate box connecting 100Mbps full duplex? Can you try putting a switch between the Netgate box and EoC equipment?Steve
-
I've asked my onsite guy to pull everything out of the site switch, connect it in between the Netgate and Cox and then configure a static in his PC and plug it into the LAN port of the Netgate to check on that.
I've also purchased support and opened a ticket with the pfSense gang. I suspect one way or another this will be resolved shortly. Support is so rarely required with pfSense that I generally only purchase it as a last resort. Sounds like we're there. ;)
-
You could have your man take a laptop and broadcast wifi from his phone and with the laptop ethernet port connect to pfsense and wifi to phone.
You could then use his laptop to see whats up with pfsense via teamviewer yourself.
I suspect you are dealing with a fat fingered typo in settings or something very simple like that.
(I did this for two of the forum members recently - Fat finger their settings I mean… :P )
-
Unfortunately we don't have any laptops onsite and my local guy hasn't been in the U.S. long enough to have re-purchased the basic amenities for himself. :)
He's actually surprisingly good. There's no way I could have achieved this with any of our other warehouse managers. If I was going to have an issue like this, I'm glad that it happened with this site. I expected a typo as well but he helped rule that out very quickly (several times…just to be sure). The only things that were changed from when it was in a working state were the static IP and the gateway address really so it was a short list of things to confirm.
I sent a copy of my config as well as some basic command line results to pfSense support yesterday and they confirmed that all was well. So far, they appear to be as stumped as I've been but are narrowing the options down.
We pulled everything apart yesterday and put a switch in between pfSense and the ISP equipment but that didn't do anything either.
-
I've set one of these up with on cable before. What version of pfsense are you running and is it 64 or 32 bit?
-
I've used pfSense quite successfully on Cable, DSL, and Fiber in the past. While Ethernet over Copper isn't hugely different, it's definitely not a cable line. The ISP's hardware does still present me with a modem-like device that sits behind the EoC bonding device.
I'm currently running pfSense 2.03. While I didn't think to look before I shipped it out, the ALIX board has an AMD Geode LX800 which I believe should mean that it's likely running the amd64 NanoBSD build but I don't know that for certain. I'll have the local guy confirm that when he gets on site today. I have a number of ALIX boards identical to this one running on both DSL and Cable installs but this is my first on EoC. Given how easily a PC connects with a static IP, I can't imagine the differences are significant…and yet here we are. :) If I hadn't already tested for it so many times already, I would feel inclined to say that it's a bad cable based upon the behaviour that I'm seeing.
-
Hmmmm - Maybe try backing up your install configuration and then installing the same box with the 32 bit version of 2.1?
See if results are better. Once, when 2.03 didn't work for me with lots of IPs 2.1 did.
-
That's certainly an option but I'll probably leave it as a last resort. Given that I have several implementations of 2.03 in the field that have been trouble free and given that this one is such a basic setup (and so far away) I'm hoping to avoid deploying an RC in production unless I have to.
-
I agree its very strange - I can only imagine a few reasons for this to happen.
There was a router of some sort previously connected and you should clone its MAC to get an IP. (This is some BS I encounter occasionally)
There is something different about this set up than your others.
I've actually not had much luck with 2.03 and more than 4 IPs. (Others maybe have. My experience with it is limited)Lastly, maybe its not a router problem at all. Maybe the ISP made an error either in what it allocated you or the info they provided you?
-
I don't thing the Geode supports 64bit. The amd64 architecture is so named because AMD introduced a 64 bit cpu before Intel did.
The switch between the EoC and Netgate box didn't help but did it change anything?
What does 'ifconfig vr1' report? If you don't have console access you can run that from Diagnostics: Command Prompt:I bet the support guys will solve this, be interesting to know what we overlooked here.
@kejianshi I thought most of those things but all of that is ruled out by the fact that the Win7 machine connects no problems with the same details. That's what made me think subnet.
Steve
-
I'll read back. Did the Win7 machine grab an IP with DHCP or was that connection manually configured?
-
The setup is a new installation so I'm pretty sure we're not dealing with a MAC issue. Especially given that we've repeatedly connected a Win7 box directly to the EoC and been able to test successfully.
I've had good luck with 2.03 in several different sizes of installation from single IP's up to 10 or 12 IPs with several LANs and QoS. It's just always treated me well.
Since I ordered the NetGate preloaded with pfSense, I feel comfortable that it's loaded correctly. Although I haven't actually checked what architecture this one is loaded with, this is the 5th Netgate that I've ordered in the last year or so and all have been rock solid.
I was suspicious of the ISP having made a mistake as well but using the same settings in that Win7 box proved to work fine so I have to assume that my connection is capable of working. In addition the onsite tech that the ISP sent out had no problems with it during setup.
I'm still waiting for my onsite guy to arrive at work this morning. I'll run some of the new tests that pfSense Support has requested when he gets in.
Here are the ifconfig results that I sent to pfSense Support yesterday. They confirmed that they were happy with what they saw there. I have supplied them with the information that the ISP supplied to me as well to ensure that they're looking at the same data that I am.
$ ifconfig -a
vr0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:0d:b9:2f:8d:a8
inet 10.2.0.1 netmask 0xffff0000 broadcast 10.2.255.255
inet6 fe80::20d:b9ff:fe2f:8da8%vr0 prefixlen 64 scopeid 0x1
nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether {myMAC}
inet {ISPSuppliedIP} netmask 0xfffffff8 broadcast {BROADCASTIP}
inet6 {ISPSuppliedInfo} prefixlen 64 scopeid 0x2
nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:0d:b9:2f:8d:aa
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
nd6 options=43 <performnud,accept_rtadv>pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
enc0: flags=41 <up,running>metric 0 mtu 1536
pflog0: flags=100 <promisc>metric 0 mtu 33200</promisc></up,running></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></broadcast,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast> -
I'll read back. Did the Win7 machine grab an IP with DHCP or was that connection manually configured?
The connection requires static IP's so the Win7 machine was manually configured with the ISP supplied info as it was entered into pfSense.
-
I'd wipe the box, reinstall and reload configuration and try again - assuming this hasn't also been tried.
But yeah - Seems like everyone knows exactly what they are doing.
-
Ethernet autoselect (100baseTX <full-duplex>)
Its not Gigabit huh?
Its probably nothing, but I'm sure the laptop was auto-negotiating a gigabit connection with the modem.
You already tried inserting a VLAN switch in between the modem and the pfsense and using 2 untagged VLAN ports?
1 plugged into the modem and 1 into the pfsense?
Its unlikely, but I've seen in the past where some gigibit equipment didn't play well with some 100base equipment (I've seen it here only once)
Anyway - I'm sure the super expert paid support guys will fix it. They are pretty good.</full-duplex>
-
Nope the Netgate m1n1wall is an Alix board with vr(4) 10/100 NICs. Otherwise auto-negotiating to 1000Mbps but the cable not being up to it would high on my list of suspects.
Definitely check that it's negotiating the speed/duplex correctly with the EoC box, ifconfig or Status: Interfaces: will show that.
I have seen some odd connection issues where the negotiation fails or the interface refuses to come up unless the remote end is already up. That can be a problem with two boxes directly connected which is why I suggested the switch.Is the Win7 box using a Gigabit NIC?
Steve
-
Given that the Netgate and the modem were both willing to autonegotiate I'm certain that they agreed on an acceptable speed. I've run into fiber media convertors that insist upon Gigabit, but that's because they won't autonegotiate. I would be impressed if that modem was Gigabit capable given that EoC's capabilities end around 1/10th of that. The ALIX board definitely isn't Gigabit.
Yeah, I've plunked a switch inbetween the two but that didn't solve it either. (thankfully!)
Yes, the Win7 box is Gigabit capable.
-
OK - This is one for the experts I guess.
I do have a small stash of this stuff. If you need, I can FEDEX overnight some to you. For a price.
http://www.youtube.com/watch?v=3nbEeU2dRBg