Minimum hardware to do symmetric gigabit wan + pass 802.1x traffic to AT&T?
-
Correct. When I was setting this up for the single pfsense I have up on an ATT fiber connection I was assured that a good bridged mode where you get a public IP at the pfsense wan was impossible.
It was very easy and straight forward. The only side effect, which for some may be a deal breaker, is that IPV6 is not convenient to work out because of the way they pass in their tunnels and authenticate it on the modem. I just pass bridged IPV4 and turned off IPV6 at the wan. I have no use for a /64 on my freakin wan.
-
Got it. Thanks everyone!!
-
For the:
Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
2 CPUs: 1 package(s) x 2 core(s)
AES-NI CPU Crypto: NoSpeedtest results vary depending on network conditions. Speedtest.net is highly variable and the comcast test is very consistent.
http://speedtest.xfinity.com/results/J98EWA1V1ACVMR0
http://www.speedtest.net/my-result/6738848123
-
None of the gateways have true bridge mode, all of the gateways have some form of half measure that provides pfSense with a public IP. This will be called something along the lines of DMZ+ or ip-passthrough. It doesn't matter to you which mode you get.
What does matter as far as which gateway you get is the NAT table size. Some of the older gateways had much smaller NAT tables, like 2k. The newer gateways are 8k+. You should get a new gateway if you are a new customer.
All gateways, regardless of model or method to get pfSense a public IP will force you to use the gateways NAT table (even though you aren't double NAT), so having that larger NAT table matters.This is 100% correct. Personally, I have the 5268AC passing through the public IP to pfSense with no issues in the 9 months or so I've had it. But I'm on VDSL. The DMZ+ mode also works fine with fiber, but the OP is looking at a workaround that is only available with fiber. It's not a true bridge mode, but it allows the AT&T CPE to handle the 802.1x auth without having to worry about the state table in the AT&T hardware. At least that's how I understand it.
That clarification aside, the hardware required on the pfSense end won't be any different than for any other 1Gbps WAN.
-
Wouldn't it be easier to just get the 802.1x details and auth directly.
-
@johnkeates:
Wouldn't it be easier to just get the 802.1x details and auth directly.
I believe it uses a certificate that is locked to the CPE.
-
Seriously surprised this DSLReports thread isn't mentioned here.. (or did I miss it?)
http://www.dslreports.com/forum/r29903721-AT-T-Residential-Gateway-Bypass-True-bridge-mode
-
Seriously surprised this DSLReports thread isn't mentioned here.. (or did I miss it?)
http://www.dslreports.com/forum/r29903721-AT-T-Residential-Gateway-Bypass-True-bridge-mode
It is practically what we have already done here.
@johnkeates:
Wouldn't it be easier to just get the 802.1x details and auth directly.
I believe it uses a certificate that is locked to the CPE.
Unless that CPE stores the super secret sauce in some sort of TPM or Secure Enclave nothing prevents you from dumping all of its storage and reading the keys you need.
-
Seriously surprised this DSLReports thread isn't mentioned here.. (or did I miss it?)
http://www.dslreports.com/forum/r29903721-AT-T-Residential-Gateway-Bypass-True-bridge-mode
I've been looking around for a clean way to use 3 NICs in the pfSense to accomplish the auth with the python or other scripts but nothing seems to work. The hardware switching with VLANs does indeed work but the pfSense will be setup for a remote site and no one technical enough to redo the process in case of a power outage. Anyone else find a simply solution?
-
[Edit: Oops, I didn't read the entire thread first. You already bought a beefy Poweredge T30 a couple months ago. Woot.]
If that's overkill, what about using something like ESXi to run pfSense (and other services) in a virtual machine? I know it's possible, but is it a good idea (in the eyes of the pfSense community)?
I'll add my two cents to this one. One of the lessons learned at a past company (when we lost power to the datacenter because of catastrophic UPS failure duriing a UPS test on a Monday at noon (go figure…idiots in charge), and recovery took 12-24+ hours... losing millions of $$$) was that critical infrastructure (such as our DNS servers and Domain Controllers) were 100% virtualized. And the back-end storage arrays for all these virtual servers? Since the array lost power abruptly it had to go through a lengthy disk check, which took hours. Meanwhile, since none of the servers that were up and running had any DNS, they were sitting ducks and useless.
Lesson learned: Virtualization is awesome, but don't virtualize 100% of your critical infrastructure. Always have at least one physical device per infrastructure type.
This is probably apples and oranges compared to a home environment, but if you want to virtualize pfSense in ESXi or any other hypervisor, just be aware that if the physical host fails or has to be rebooted (etc), your pfSense router, firewall, DNS, DHCP, and any other critical services will be down during that time. So for highest availability, have at least one physical pfSense device, and feel free to virtualize the others. Or have two virtual pfSense instances on two separate physical ESXi servers.
Totally overkill answer, especially for home. But it was a painful lesson learned and one I will always think about when I implement infrastructure, even at home. :P
-
I've been using the Pace 5268AC in a different configuration using CARP IP Aliases for years with U-verse, but then I upgraded to AT&T Fiber I discovered that the Add Cascade Router option is now working. It appears to be a true IP Pass-through, so I created the following post to help others out:
