aus
join:2018-09-22
united state
1 edit
3 recommendations |
aus
Member
2018-Sep-22 6:13 pm
True Bridge mode on pfSense with IPv6 via netgraphHi all... I know True Bridge mode has been a heavily discussed topic. Most have had success with the VLAN swap trick or via ebtables or eap_proxy in Linux. However, neither of those worked for me. I just wanted to share my notes on getting things working in pfsense. Hopefully it helps! » github.com/aus/pfatt |
|
 jsolo1
Premium Member
join:2001-07-01
PRIL
1 recommendation |
jsolo1
Premium Member
2018-Sep-23 12:04 am
Re: True Bridge mode on pfSense with netgraphIpv6 works with this method? |
|
2 recommendations |
This is a clever use of netgraph. Thanks for sharing!
The solution should work with both IPv4 and IPv6 as it operates between the physical NIC and IP stack. Just configure IPv6 as usual on the ngeth0 virtual interface. |
|
badbread
join:2005-01-18
San Francisco, CA
1 recommendation |
to aus
Is this a "set it and forget" type fix? No manual configuration after power loss, act of god, etc...?
Thanks!! |
|
|
aus
join:2018-09-22
united state
3 recommendations |
aus
Member
2018-Sep-24 3:30 pm
said by jsolo1:Ipv6 works with this method? I concur with @ryan3531. It should just work, though I haven't personally been through the steps to getting my DHCP6 client configured. Any pointers in getting U-Verse DHCPv6 configured on pfSense would be helpful! said by badbread:Is this a "set it and forget" type fix? No manual configuration after power loss, act of god, etc...?
Thanks!! Pretty much. Once pfSense is configured with the proper netgraph (which should happen early at boot via the pfatt script), everything just works. EAP authentication is always bridged between the gateway and ONT. And the WAN is properly tagged as VLAN0. Should survive reboots, EAP reauths, etc. No performance impacts. The only scenario where this might fail is if AT&T pushes a new certificate to your gateway and expires your old one. In theory, this could be captured and directed via netgraph too. But without any pcaps to go off of, there's not much you can do. All that is pure speculation though. |
|
aus
3 recommendations |
aus
Member
2018-Sep-25 12:02 am
I added my notes on getting IPv6 running. These should also work if you aren't using netgraph. » github.com/aus/pfatt |
|
badbread
join:2005-01-18
San Francisco, CA
1 recommendation |
to aus
So I gave this a try last night... Let me start by saying I'm no network engineering guru, but do know a little bit... After about 3 hours, a full PFSense reinstall, and countless restores I gave up for the night. Was hoping to get some help in figuring out what I'm doing wrong...
My PFsense box is setup as follows:
em0 - Guest
em1 - LAN
em2 - Primary WAN (ATT) - I moved this after setting up the script and kernel to em5
em3 - nothing
em6 - Backup WAN (Comcast)
OPT1-4 - Various VPN's clients and a server
em4 - ONT (post script/kernel install)
em5 - Gateway ($RG_IF) plugged into the gateway port 1
I was able to copy the files over and modify them correctly (I think): edit the script, change perms, set script executable, set kernel perms to 555, etc...
On the first reboot after setting up the script and kernel PFSense wanted to reconfigure all of my interfaces like it was a new install. I'm pretty sure that's what it is suppose to do but I'm not 100% sure what to do there. Do I need to setup all my interfaces again? Iit asks about setting up VLAN's and I'm not sure what to do for that.
If I CTRL-C out of that, it brings up PFSense with all the old interfaces and then I can see the new interface (ngeth0)
I tried changing em2 (ATT) to ngeth0 but it doesn't get out to the internet.
I did a tcpdump -ei on the $ONT_IF but saw no traffic at all.
tcpdump on $RG_IF shows lots of traffic and broadcasts but I never saw the EAPOL type in there
The prepopulated MAC address of ngeth0 matches the RG, I also tried spoofing it in the interface setting to no avail. Rebooted the RG multiple times and still never saw the EAPOL packets come through.
I have to double check tonight what kind of traffic (if any) was on ngeth0, I can't remember it was a late night.
Tried clearing netgraph as the readme says but that broke lots of stuff and I had to restore.
Also, on the ATT gateway, should it be set to passthrough mode or something else?
Sorry if this is confusing, appreciate any thoughts or help. |
|
aus
join:2018-09-22
united state
3 recommendations |
aus
Member
2018-Sep-25 4:38 pm
Sorry you had some trouble with this! I definitely know the feeling. I think you were close. And I think the problem was pretty simple. said by badbread:em5 - Gateway ($RG_IF) plugged into the gateway port 1 $RG_IF should be plugged into the ONT port of the Gateway. $ONT_IF should be plugged with the cable that goes outside to your ONT. It's normal to see pfSense wanting to reconfigure your interfaces. Once it sees ngeth0, it gets confused and it's unsure which to assign to WAN. You don't need to reconfigure all of your interfaces in the pfSense webConfigurator/shell wizard. You just have to assign the WAN interface to ngeth0. said by badbread:I did a tcpdump -ei on the $ONT_IF but saw no traffic at all. This is expected. You won't see anything until authenticate. said by badbread:tcpdump on $RG_IF shows lots of traffic and broadcasts but I never saw the EAPOL type in there If you were plugged into Port 1-4 of the gateway, I would expect this. $RG_IF needs to be plugged into the Orange ONT port of your Gateway. Then you should see some EAPOL STARTS. If your netgraph is setup correct, these EAPOL STARTs should get bridged to your $ONT_IF and you should see the handshake occur. After that, ngeth0 will send DHCP requests. If the MAC address is correct and ngetgraph is correct tagging to VLAN0, it should assign you an IP. said by badbread:Tried clearing netgraph as the readme says but that broke lots of stuff and I had to restore. You had to restore pfSense? pfSense does interface with netgraph for interfaces it manages. If you reset your netgraph, you effectively delete the ngeth0 interface, which might cause things to go array. But nothing a reboot won't solve. said by badbread:Also, on the ATT gateway, should it be set to passthrough mode or something else? The AT&T gateway should be factory default. No passthrough configured. But it probably doesn't matter either way though. Netgraph is configured to only bridge the 802.1/X traffic from the gateway. Everything else goes into oblivion. Also, you might hold off on adding the script to autoboot and just run it manually to debug first. In summary... - $RG_IF ----> Connects to your AT&T Gateway on the ONT Port - $ONT_IF ---> Connects to the outside (ONT) - Neither interface needs to be managed by pfSese (ie added as an enabled Interface). - ngeth0 should be configured as your WAN with the MAC spoofed. - $RG_IF probably needs to be in promiscuous mode +--------------------+ +--------------+ +--------------+
| | | | | |
| AT&T Gateway | | | | |
| | | ONT | | LAN |
+--------------+-----+ | (outside) | | |
| ONT | | | | |
| Port| | | | |
+--+--+ +-------+------+ +-------+------+
| | |
| | |
+----+-+ +---+---+ +-+-+
|$RG_IF| |$ONT_IF| |LAN|
+-----+----------------+------------------------+
| | | |
| +----------------+ |
| | netgraph | |
| +----------------+ |
| |ngeth0 (WAN)| |
| +------------+ pfSense |
| |
| |
+-----------------------------------------------+
|
|
badbread
join:2005-01-18
San Francisco, CA
1 recommendation |
Thanks so much! I'll give it another shot tonight, I enjoy breaking things so I can fix them!  Thanks again! |
|
aus
join:2018-09-22
united state
3 recommendations |
aus
Member
2018-Sep-25 11:28 pm
I added some more notes to my repo, badbread. Hopefully that helps you troubleshoot! |
|
badbread
join:2005-01-18
San Francisco, CA
1 recommendation |
Thanks aus, just read through it and now I get a much better understanding of what's going on. Thank you! I'm running into a problem when I assign ngeth0 to the existing ATT interface. em2 is my ATT WAN interface I make this change to the physical wiring: $ONT_IF = 'em3' # (going to the physical ONT box) $GW_IF = 'em4' # (going to the ONT port on the gateway) I then tried to change em2 to ngeth0. When I do it through the webui it acts as if it's trying to refresh the page (that slight pause when you save something in PFSense) but never successfully reloads the interface page with the saved changes. Refreshing the PFSense default menu (via direct console/SSH) never shows ATT -> ngeth0, it stays stuck at ATT -> em2. When I reboot after making the above interface change, there is a message that says Warning: Configuration references interfaces that do not exist: ngeth0
Network Interface Mismatch -- Running Interface assignment option.
PFsense then asks if I want to setup VLANS and then goes through what I'm assuming is it's initial setup for WAN/LAN. Am I doing everything right now? I'm on 2.4.4, maybe that's why?? Is there a way to get around that configuration on reboot that I'm missing??? Thanks again and sorry my ignorance, I'm not the sharpest tool in the shed. :) **EDIT** Running a tcpdump on em3 or em4 shows absolutely nothing... Not sure what I messed up. |
|
aus
join:2018-09-22
united state
3 recommendations |
aus
Member
2018-Sep-26 10:36 am
said by badbread: When I do it through the webui it acts as if it's trying to refresh the page... This hang happens for me too sometimes. I believe the hang is associated with pfSense waiting for a DHCP lease. If it never receives one, it eventually adds the interface anyways. But I've never had a problem with it being "stuck". That is strange... said by badbread:I'm on 2.4.4, maybe that's why?? Maybe. the ng_etf module was compiled against FreeBSD 11.1 which is what pfSense 2.4.3 uses. But pfSense 2.4.4 uses FreeBSD 11.2 which could be potentially different... I'll have to look into that but I would expect it work on pfSense 2.4.4. said by badbread:Running a tcpdump on em3 or em4 shows absolutely nothing... em3 is expected to show nothing on the tcpdump until the 802.1/X authentication is complete. You should see some EAPOL-STARTs on em4/$RG_IF. If those arent being bridged, then something is wrong with netgraph. said by badbread:there is a message that says ... interfaces do not exist netgraph creates ngeth0 as a virtual interface. if the interface is not there, it is because netgraph hasn't created it or the netgraph node was deleted. Let's first try and confirm the 802.1/x auth is being completed. Try this... 1. Move pfatt.sh out of /usr/local/etc/rc.d to /root or something. We will execute it manually. 2. Reboot and restore to your normal configuration. 3. After reboot, get to a shell on your pfsense box. Local access is better in case you screw up your LAN interface. But SSH will probably work too and is better for managing multiple sessions. 4. Ensure pfatt.sh is configured as follows (assuming these are your correct interfaces): ONT_IF = 'em3' # (going to the physical ONT box)
RG_IF = 'em4' # (going to the ONT port on the gateway)
RG_ETHER_ADDR='xx:xx:xx:xx:xx:xx' # matches your MAC of your Residential gateway
5. Run pfatt.sh. You should see a bunch of output. If you see "done!" that means there were no errors. 6. Start a tcpdump on $RG_IF: tcpdump -ei em4 -vv
7. Unplug the $RG_IF / em4 cable, wait a few seconds and plug it back in. Watch the tcpdump. This should initiate the Residential Gateway to attempt an EAPOL-START again. It should only be a few packets at a time. If you see some responses to your START, great! That means you were authenticated. If not, something is not right. Report back and we will go from there. Also, are you running pfSense virtualized? or on physical hardware? |
|
3 recommendations |
I'll have to give this a shot over the weekend when I can get minimal complaining from the SO. Will update here when I do, thanks for the write-up aus, and here's to hoping I can get it up. |
|
 maartenaElmo
Premium Member
join:2002-05-10
Orange, CA
1 recommendation |
to aus
Re: True Bridge mode on pfSense with IPv6 via netgraphI think I already know the answer to my own question, but I will ask it nonetheless.... I have a PFSense unit in production with 3 NIC's, 2 x 1 Gbit/s Intel NIC's one on-board, one add-on PCI card, currently in use as LAN and WAN... and I have full gig 940/940 speeds. I also inserted some time ago a 100 Mbit/s cheap crappy leftover adapter as a third adapter (the OPT interface in PFSense) with the idea of running a physically separate guest network using "Redneck QOS" by means of the 100 Mbit/s adapter, but I never set it up.... as I went with Ubiquiti gear, and ended up with a nice guest portal and whatnot.
Is the 100 Mbit/s adapter sufficient enough for the communication bits the AT&T Gateway needs to do? I would imagine the answer is YES, but just wanted to be sure. |
|
jsolo1
Premium Member
join:2001-07-01
PRIL
1 recommendation |
jsolo1
Premium Member
2018-Sep-26 2:38 pm
^^I'm sure the experts will chime in shortly. Realistically unless there's more to it, I can't see the whole authentication sequence consuming that much data. Probably measured in terms of kilobytes or even bytes. For that, even a 10mbit connection should work.
Since I started using the bypass back in april or may, I can count on one hand how many times the gateway has been reconnected. Mostly when I need to take the firewall offline but don't want to hear complaints of no internet. Albeit certain devices still don't work because they're on vlans and the rgw has no idea how to handle them. |
|
aus
join:2018-09-22
united state
1 recommendation |
aus
Member
2018-Sep-26 2:57 pm
100 Mbps is definitely sufficient for occasional 802.1X auth procedure. Even 100Mbpy (that's 100 Megabit per year) would probably work! |
|
1 recommendation |
to aus
Could the same technique be used for adsl2+? Assuming there's a modem that's compatible. |
|
aus
join:2018-09-22
united state
1 recommendation |
aus
Member
2018-Sep-26 5:52 pm
Maybe. I'm not familiar with how the ADSL2+ service works. Assuming it uses 802.1/X, VLAN0 and DHCP, then it should work. But if it is at all different, netgraph might need to be tweaked to your enviornment.
A packet capture of the router bootup sequence would confirm (but be careful posting these in the public domain). |
|
badbread
join:2005-01-18
San Francisco, CA
4 edits
1 recommendation |
to aus
Re: True Bridge mode on pfSense with netgraphIt's a physical server. Moved the pfatt.sh script out of rc.d and manually ran it after a reboot of PFsense. ./pfatt.sh: pfSense + AT&T U-verse Residential Gateway for true bridge mode
Configuration:
ONT_IF: em3
RG_IF: em4
RG_ETHER_ADDR: no:MA:Ca:dd:re:ss:Fo:rY:ou
loading netgraph kernel modules... OK! (any 'already loaded' errors can be ignor ed)
attaching interfaces to ng_ether... OK!
building netgraph nodes...
creating ng_one2many... OK!
creating vlan node and interface... OK!
defining etf for em3 (ONT)... OK!
defining etf for em4 (RG)... OK!
bridging etf for em3 <-> em4... OK!
defining filters for EAP traffic... OK!
enabling one2many links... OK!
removing waneapfilter:nomatch hook... OK!
ngeth0 should now be available to configure as your pfSense WAN
done!
Tried to do tcpdump on em4 (cable connected to the ONT port of the gateway) shows no traffic at all, not a single packet, even after rebooting the GW. I'm swapping in another NIC now to see if maybe the em4 NIC is bad or something... *** EDIT *** Some success!! I tried another NIC card and I'm finally seeing: 21:25:47.667761 xxx (oui Unknown) > xxx (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL logoff (2) v2, len 0
21:25:47.667780 xxx (oui Unknown) > xxx (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
21:26:18.942472 xxx (oui Unknown) > xxx (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
Setup the ATT interface to use ngeth0 but it's not grabbing a DHCP address. Verified the MAC address and hard coded the MAC into the ATT interface. Thanks again! Getting closer! *** EDIT 2 *** Just taking some shots in the dark, tried creating a interface with ngeth0 and still no DHCP *** EDIT 3 *** With a new interface setup and set to use ngeth0 I tried moving the pfatt.sh script back to ../rc.d, rebooted and pfsense throws the warning: warning: configuration references interfaces that do not exist: ngeth0
... at which point it asks me to reconfigure each interface. Thanks and let me know what else I can do to help! |
|
aus
join:2018-09-22
united state
3 recommendations |
aus
Member
2018-Sep-27 11:44 am
Getting closer! That's interesting that swapping out the NIC card enabled you to see the EAPOL. Very strange. I know Intel NICs are supported best in BSD and are generally just better cards. But even so, I would expect this to work on any NIC. pfatt.sh output looks good! Now that we are seeing the EAPOL on $RG_IF, we can do some further debugging. I don't want to worry about DHCP just yet. We need to confirm 802.1/X EAPOL authentication sequence works. Otherwise DHCP definitely will not work. So let's try this... 1. Get to environment where you have a working LAN (ie ability to SSH, no internet access is required for this). It might also be a good idea to make sure that $RG_IF and $ONT_IF are not "managed" NICs in pfSense. In Interfaces > Assignments, remove or delete any reference to $RG_IF or $ONT_IF. That gets pfsense mostly out of the way. I have noticed that pfSense will in some cases alter the netgraph. And we dont want to worry about that at this point. 2. Run the script again. Confirm "done!". Then run the tcpdump on $RG_IF again and confirm the EAPOL starts are showing again. 3. Keep that tcpdump running. In another session, let's inspect the $ONT_IF with tcpdump... tcpdump -ei $ONT_IF -vvv
4. Do you see any traffic? Try unplugging and replugging in cables, rebooting the RG, etc. Any thing? The EAPOL STARTs from $RG_IF should be bridged to $ONT_IF by netgraph and the auth sequence should complete. And sometimes it takes several seconds for the the ONT to respond to the START. 5. If you dont see any traffic on $ONT_IF, then something might not be right with netgraph. Post the output from these commands. It may hold some helpful debug info... ifconfig $RG_IF
ifconfig $ONT_IF
<some output of tcpdump $RG_IF. pcaps might be helpful too>
<some output of tcpdump $ONT_IF. pcaps might be helpful too>
kldstat -v | grep ng_
kldstat -v | grep netgraph
ngctl dot
ngctl list
ngctl show $RG_IF:
ngctl show $ONT_IF:
6. If you do see a bunch of new EAPOL traffic, then you are likely authenticated. It's at this point when we can focus on ensuring VLAN0 is being tagged. Then DHCP. We can verify this by looking at tcpdumps on $ONT_IF and ngeth0. Give that a shot and let me know. Oh and regarding the "interface does not exist" error. I need to do some more testing on bootup. This is likely a race condition where pfsense tries to configure ngeth0 before netgraph has created it. There might be a way to start pfatt.sh earlier in the boot sequence. Until I figure that out, just run it manually outside of rc.d. |
|
badbread
join:2005-01-18
San Francisco, CA
3 edits
1 recommendation |
to aus
Re: True Bridge mode on pfSense with IPv6 via netgraph**EDIT** Not seeing any traffic at all in the TCPDumps and I have no idea why. Last night I was getting something. Only difference this time is I removed "em2" which normally is the ATT WAN link. I'm sorry if I should have said this earlier but the modem I'm using is the BGW210. I still have my Comcast WAN link as well (em6) not sure if that matters. The BGW 210 Broadband light flashes fast red when I move the cables around, not sure if that means anything. I'm guessing something is wrong with netgraph? Also, I noticed in the bootup process the CRON section doesn't fire until after the interfaces are setup, maybe that explains why it doesn't find ngeth0. **EDIT 2** If I create a new interface using ngeth0 I see these on em2($rg_if) (but not on em3 $ont_if) every 30 seconds or so: [2.4.4-RELEASE][admin@pfSense.bread]/home/badbread: tcpdump -ei em2 -vvv
tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 262144 bytes
21:31:52.370418 xxxx (oui Unknown) >xxxx (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
Here's the debugging info: [2.4.4-RELEASE][admin@pfSense.bread]/home/badbread: ./pfatt.sh
./pfatt.sh: pfSense + AT&T U-verse Residential Gateway for true bridge mode
Configuration:
ONT_IF: em3
RG_IF: em2
RG_ETHER_ADDR: xxxxxxxx
loading netgraph kernel modules... OK! (any 'already loaded' errors can be ignored)
attaching interfaces to ng_ether... OK!
building netgraph nodes...
creating ng_one2many... OK!
creating vlan node and interface... OK!
defining etf for em3 (ONT)... OK!
defining etf for em2 (RG)... OK!
bridging etf for em3 <-> em2... OK!
defining filters for EAP traffic... OK!
enabling one2many links... OK!
removing waneapfilter:nomatch hook... OK!
ngeth0 should now be available to configure as your pfSense WAN
done!
Running tcpdump on both em2 and em3 show nothing, cable reconnect, gw reboot: [2.4.4-RELEASE][admin@pfSense.bread]/home/badbread: tcpdump -ei em2 -vvv
tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 262144 bytes
rebooting GW
2 minutes later nothing
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[2.4.4-RELEASE][admin@pfSense.bread]/home/badbread:
----------------------------------------------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: tcpdump -ei em3 -vvv
tcpdump: listening on em3, link-type EN10MB (Ethernet), capture size 262144 byte s
rebooting GW
2 minutes later nothing^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
[2.4.4-RELEASE][admin@pfSense.bread]/root:
[2.4.4-RELEASE][admin@pfSense.bread]/root: ifconfig em2
em2: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether xxxx
hwaddr xxxx
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: ifconfig em3
em3: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether xxxx
hwaddr xxxx
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: kldstat -v | grep ng_
547 ng_socket
532 ng_ether
531 ng_eiface
546 ng_rfc1490
545 ng_pred1
530 ng_echo
544 ng_pptpgre
543 ng_pppoe
529 ng_deflate
542 ng_ppp
522 ng_UI
541 ng_pipe
528 ng_cisco
527 ng_car
540 ng_one2many
539 ng_mppc
526 ng_bridge
538 ng_lmi
537 ng_l2tp
523 ng_async
536 ng_ksocket
525 ng_bpf
535 ng_iface
534 ng_hole
533 ng_framerelay
552 ng_vlan
551 ng_vjc
550 ng_tty
549 ng_tee
548 ng_tcpmss
6 1 0xffffffff8352d000 a04 ng_etf.ko (/boot/kernel/ng_etf.ko)
671 ng_etf
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: kldstat -v | grep netgraph
524 netgraph
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: ngctl dot
graph netgraph {
edge [ weight = 1.0 ];
node [ shape = record, fontsize = 12 ] {
"21" [ label = "{\<unnamed\>:|{socket|[21]:}}" ];
"3" [ label = "{em2:|{ether|[3]:}}" ];
"4" [ label = "{em3:|{ether|[4]:}}" ];
"5" [ label = "{em4:|{ether|[5]:}}" ];
"6" [ label = "{em5:|{ether|[6]:}}" ];
"29" [ label = "{o2m:|{one2many|[29]:}}" ];
"a" [ label = "{\<unnamed\>:|{socket|[a]:}}" ];
"2c" [ label = "{vlan0:|{vlan|[2c]:}}" ];
"4e" [ label = "{ngctl46253:|{socket|[4e]:}}" ];
"2f" [ label = "{ngeth0:|{eiface|[2f]:}}" ];
"33" [ label = "{waneapfilter:|{etf|[33]:}}" ];
"37" [ label = "{laneapfilter:|{etf|[37]:}}" ];
"1a" [ label = "{snmpd:|{socket|[1a]:}}" ];
};
subgraph cluster_disconnected {
bgcolor = pink;
"21";
"5";
"6";
"a";
"4e";
"1a";
};
node [ shape = octagon, fontsize = 10 ] {
"3.upper" [ label = "upper" ];
"3.lower" [ label = "lower" ];
};
{
edge [ weight = 2.0, style = bold ];
"3" -- "3.upper";
"3" -- "3.lower";
};
node [ shape = octagon, fontsize = 10 ] {
"4.lower" [ label = "lower" ];
};
{
edge [ weight = 2.0, style = bold ];
"4" -- "4.lower";
};
node [ shape = octagon, fontsize = 10 ] {
"29.many1" [ label = "many1" ];
"29.many0" [ label = "many0" ];
"29.one" [ label = "one" ];
};
{
edge [ weight = 2.0, style = bold ];
"29" -- "29.many1";
"29" -- "29.many0";
"29" -- "29.one";
};
"29.one" -- "4.lower";
node [ shape = octagon, fontsize = 10 ] {
"2c.vlan0" [ label = "vlan0" ];
"2c.downstream" [ label = "downstream" ];
};
{
edge [ weight = 2.0, style = bold ];
"2c" -- "2c.vlan0";
"2c" -- "2c.downstream";
};
"2c.downstream" -- "29.many0";
node [ shape = octagon, fontsize = 10 ] {
"2f.ether" [ label = "ether" ];
};
{
edge [ weight = 2.0, style = bold ];
"2f" -- "2f.ether";
};
"2f.ether" -- "2c.vlan0";
node [ shape = octagon, fontsize = 10 ] {
"33.eapout" [ label = "eapout" ];
"33.downstream" [ label = "downstream" ];
};
{
edge [ weight = 2.0, style = bold ];
"33" -- "33.eapout";
"33" -- "33.downstream";
};
"33.downstream" -- "29.many1";
node [ shape = octagon, fontsize = 10 ] {
"37.eapout" [ label = "eapout" ];
"37.nomatch" [ label = "nomatch" ];
"37.downstream" [ label = "downstream" ];
};
{
edge [ weight = 2.0, style = bold ];
"37" -- "37.eapout";
"37" -- "37.nomatch";
"37" -- "37.downstream";
};
"37.eapout" -- "33.eapout";
"37.nomatch" -- "3.upper";
"37.downstream" -- "3.lower";
}
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: ngctl list
There are 13 total nodes:
Name: <unnamed> Type: socket ID: 00000021 Num hooks: 0
Name: em2 Type: ether ID: 00000003 Num hooks: 2
Name: em3 Type: ether ID: 00000004 Num hooks: 1
Name: em4 Type: ether ID: 00000005 Num hooks: 0
Name: em5 Type: ether ID: 00000006 Num hooks: 0
Name: o2m Type: one2many ID: 00000029 Num hooks: 3
Name: <unnamed> Type: socket ID: 0000000a Num hooks: 0
Name: vlan0 Type: vlan ID: 0000002c Num hooks: 2
Name: ngeth0 Type: eiface ID: 0000002f Num hooks: 1
Name: ngctl15084 Type: socket ID: 00000050 Num hooks: 0
Name: waneapfilter Type: etf ID: 00000033 Num hooks: 2
Name: laneapfilter Type: etf ID: 00000037 Num hooks: 3
Name: snmpd Type: socket ID: 0000001a Num hooks: 0
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: ngctl show em2:
Name: em2 Type: ether ID: 00000003 Num hooks: 2
Local hook Peer name Peer type Peer ID Peer hook
---------- --------- --------- ------- ---------
upper laneapfilter etf 00000037 nomatch
lower laneapfilter etf 00000037 downstream
-------------------------------
[2.4.4-RELEASE][admin@pfSense.bread]/root: ngctl show em3:
Name: em3 Type: ether ID: 00000004 Num hooks: 1
Local hook Peer name Peer type Peer ID Peer hook
---------- --------- --------- ------- ---------
lower o2m one2many 00000029 one
As always, thanks very much! |
|
aus
join:2018-09-22
united state
1 recommendation |
aus
Member
2018-Sep-28 1:42 am
First thought: Try putting $RG_IF into promiscuous mode. I added this to pfatt.sh a few days ago. I thought it was required for just my NIC, but after thinking about it more I think its probably required for everyone.
I'll try and think of some more ideas tomorrow... |
|
aus
3 recommendations |
aus
Member
2018-Sep-28 7:25 pm
I did a little more testing today and found some circumstances where I could not see packets in tcpdump as well. I made changes to the repo, but the gist of it is that a) the interfaces need to be up, I guess pfsense sometimes marks them as down if they arent managed by pfsense and b) both $RG_IF and $ONT_IF need to be in promiscuous mode.
I also switch from rc.d to <earlyshellcmd> for the boot process. This seems to be more stable. |
|
badbread
join:2005-01-18
San Francisco, CA
1 edit
1 recommendation |
to aus
It's working! Copied the new script over, manually ran it, changed my ATT interface to NGETH0 and success!! Thanks so much for this and all your help, really appreciate it! ** EDIT ** Unfortunately speed tests are slow (more so the upload which is opposite what it normally is) and there is an error that is appearing in the webgui: Filter Reload
There were error(s) loading the rules: pfctl: ngeth0: driver does not support altq - The line in question reads [0]: @ 2018-09-28 22:00:17
** EDIT2 ** Got rid of my traffic shapers and no longer have the above error, and speeds are fine now. Yay! |
|
aus
join:2018-09-22
united state
1 recommendation |
aus
Member
2018-Sep-29 11:00 am
Awesome! That's great to hear. And thanks for the testing. You definitely helped weed out a few bugs.
Glad you were able to work around the ALTQ issue. I guess ng_eiface does not support ALTQ. However, if it's really important to you it looks like ng_iface does support ALTQ. This node could be added as another layer of abstraction potentially.
Or a better solution might even just be to point your filter rules to the physical interface ($ONT_IF) instead of ngeth0. I think you would still get the same effect. |
|
1 edit
1 recommendation |
to aus
I would like to report success with v2.4.4 and this setup. I did personally compile ng_etf on a FreeBSD 11.2 VM.
My only snag was I had tried this in the path and had a line in loader.conf to pull in ng_etf causing some confusion. After removing that and a reboot things are smooth.
UPDATE: I am seeing a slight downgrade in speed throughput than I had for the bypass method. I do have some weird cabling from the ONT to the Firewall and going to swap to a straight cable tomorrow night.
Any one else getting ~600-700 in performance when they were getting ~800-900 with bypass? |
|
aus
join:2018-09-22
united state
1 recommendation |
aus
Member
2018-Sep-30 10:15 pm
Glad you had some success!
I can't speak for the VLAN bypass method. (My switch didn't seem to be compatible with this method.) However, I can say that my speeds are very similar, if not identical, compared to the stock gateway setup. Using a Dell R210 ii on a E3-1220.
Do you see a high % of interrupts during your speed test? What about systat -vmstat? I'm definitely no performance expert, but it look like there are some net.graph sysctls we can tweak too? Defaults seem ok for me. |
|
ramsaso
Premium Member
join:2014-01-04
Houston, TX ARRIS SB6183
1 edit
1 recommendation |
ramsaso
Premium Member
2018-Sep-30 10:24 pm
I was wondering, is there any way to simplify the way to achieve this?
I just moved out of my parent's unit and into my own and I got AT&T Fiber 1Gig and I got confused on the first step since I'm a n00b (I hate leet speak).
EDIT: I got it to work by using a graphical interface and I have the ONT connected to the pfSense box I use and em1 for LAN and em2 for RG.
Still trying to configure ipv6 but hopefully, it'll work out. I notice my speeds are better. |
|
1 recommendation |
to aus
Here is a screenshot of the command during a speedtest. I am not sure what else could be the case but I am using the on-board NIC of my C2758 motherboard. My igb0 (Was the old WAN port) is on the ONT and igb3 is now on the RG. |
|
aus
join:2018-09-22
united state
3 recommendations |
aus
Member
2018-Oct-1 10:39 am
said by ramsaso:I was wondering, is there any way to simplify the way to achieve this?
I just moved out of my parent's unit and into my own and I got AT&T Fiber 1Gig and I got confused on the first step since I'm a n00b (I hate leet speak). Hi ramsaso. Sorry you are having trouble with this. If Step 1a) is too confusing to you, I'd suggest brushing up on some command line and sysadmin basics. Else, you may struggle even with basic pfsense administration. If you were confused by Step 1b), that is an alternative to Step1a). While 1a is a quicker option, 1b is the proper and more secure method. » github.com/aus/pfattsaid by pyrodex1980:Here is a screenshot of the command during a speedtest.
I am not sure what else could be the case but I am using the on-board NIC of my C2758 motherboard. My igb0 (Was the old WAN port) is on the ONT and igb3 is now on the RG. Hmm.. nothing looks too suspicious to me. Is this before or after your cable changes? I guess netgraph is happening in kernel space, so maybe there's a way to dig more into that 11.8% sys with dtrace. If you have 8 cores, that'd almost be an entire core right? |
|
