Messages

,
Franco

Congrats on finally implementing the vlan 0 patches for wpa_supplicant. Why did it take so long?  Pfsense had it back in june of 2023.

Correctness?

On linux based firewalls, the whole vlan0 (and dhclient listening on vlan0) was never an issue.  It just worked without any modifications.

Never mind........

Here's some pics

Stuck here


serial port setting


If I enable the serial port at the default 3f8, irq 4, system boots but get no video.

If I change it to address 3e8, irq 4, system boots and I get video.

Similar behavior with the latest pfsense (development v27.xx).  So something freebsd related, and/or goofy with the motherboard (which is on the latest bios).

Board - Asus TUF GAMING Z690-PLUS WIFI D4
cpu - intel 12700K
ram - 32GB

This is my test system and completely bare bones. Using onboard video.

Attempting to install from a flash drive, the installer boots up to

Code Select Expand


atrtc0: <AT realtime clock> port 0x70-0x77 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0

Then just locks.

Earlier I see something relating to a serial port.  The onboard serial port however is disabled.

Enabling it and changing the address/irq assignment seems to allow the installer to continue booting and actually get to the point where either the live version or installer option becomes available.

There is no physical serial port installed to the motherboard header.  It's unclear why the OS is even detecting anything related to a serial port when disabled in the bios.

I tried both the vga and dvd medias with same result.  Sure I can leave the serial port enabled in the bios, but would like to understand why this is happening.

Thoughts?

Did you ever get your power usage issue figured out?

Did you ever get the dhcp issue resolved?

Full bypass has been achieved.  See this thread over at dslr for config details for UTM.  Similar method works with other platforms too (there's instructions in a different thread on doing it with pfsense which should translate well to opnsense).

https://www.dslreports.com/forum/r31927134-ATT-Fiber-Sophos-UTM-instead-of-gateway

I've only started to explore opnsense.  On sophos utm, routes were automatically created with any new interface but were not operational until creation of firewall rules allowing traffic from/to one interface to another. I'm still figuring out opnsense but maybe this is somehow applicable too.

Just to clarify, the issue is accessing internet from the vlan when the ipsec tunnel is enabled? 

Vlan's are a level 2 concept.  IP addresses are level 3.

You need to define your vlans in your unifi switch.  They can be port based of tag based. IE, you can define a set of ports (say 1-5) to be on vlan 5.  You can define any subnet on that vlan you wish.   

Or you can define multiple vlans on a single port.  To do so, you must use vlan tags.  The whole vlan concept can be confusing at first, but it's really not.  It's mainly a way of separating your network on a switch level.  You can even have same subnet on different vlans (not sure why you'd want to, but it's possible).  Each would be it's own isolated network.

Ironically enough, it was *that* thread that prompted me to spend $300+ on a qotom box.

I started out with utm because it was far more novice friendly than other options.  Lately i've been exploring pfsense because utm while a great option is somewhat bloated.  In fact, in the course of trying to get an att gateway bypass working (see https://forum.opnsense.org/index.php?topic=7298.msg37970#msg37970), I needed a more plain vanilla freebsd environment.  Discovered opnsense!  While I was only partially successful with that bypass method (great reduction in speeds) I got a nice opportunity to explore this software.

For now, utm is still the primary firewall/router, but as time permits, I do have opnsense running on a test box so I can figure out it's ui and general operating methods.  Utm has a number of firewall rules, several vpn servers and other functions enabled.  I'm slowly exploring the opnsense equivalents to these.

As for the qotom box, it's now 8 months old.  So far no issues.  Had some heat problems early on which I took care of by using one of those afinity external usb fans.  At some point I may take it apart and redo the thermal pad.

Also, everything is running under exsi.  In addition to the firewall there's freepbx and a cyberpower systems vm appliance for monitoring the connected UPS.  If power should go out, it gracefully shuts all the vm's and exsi down.  Upon power return everything starts back up. 

[With that config, the PACE gateway would always show green lights and the service was up. However, unplugging the PACE gateway and plugging in OPNsense with the spoofed MAC did not pull an IP address.]

I don't have screenshots of the setup and I'm not using the switch anymore so I can't post an exact config at this point. I'm going from memory but basically, what I recall is this.

I could use a "dumb" switch to always get the PACE gateway online. It looked like this:
ONT -----> DumbSwitchPort1
PACE ---> DumbSwitchPort2

With that config, the PACE gateway would always show green lights and the service was up. However, unplugging the PACE gateway and plugging in OPNsense with the spoofed MAC did not pull an IP address.

Using the same setup, but with a statically assigned VLAN, the OPNsense WAN port then pulled an IP. Something about the VLAN tagging between the gateway and the ONT was causing the dumb switch to not push all the traffic to the OPNsense box. Manually setting a static VLAN (such as VLAN10, or VLAN5, it doesn't matter) pushes all of the VLAN0 traffic between the switch ports defined with the static VLAN and allowed the OPNsense WAN port to receive the traffic and pull an IP. After that it was off to the races. It worked very well. Also worth noting, I only had Internet service, I did not have any TV or phone service. So this may be entirely different if you have other services riding inline with the internet service.

This is just WACK!!@#

Reread your post above several times. Your comment about the dumb (unmanaged) switch got the gears rolling.

I have a very plain basic 5 port gigabit dlink switch.  This is nothing special, about as basic as it gets.. Power brick outputs to a mini usb connector basic. https://www.amazon.com/D-Link-5-Port-Gigabit-Switch-DGS-1005G/dp/B003X7TRWE

BEFORE

Wan dhcp log going through the RGW passthrough (ONT<>RGW<>utm/pfsense)

Code Select Expand


2018:05:01-14:19:44 utm dhclient: DHCPREQUEST on eth1 to 192.168.1.254 port 67
2018:05:01-14:19:47 utm dhclient: Killed old client process
2018:05:01-14:19:48 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:19:49 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:19:49 utm dhclient: DHCPACK from 192.168.1.254
2018:05:01-14:19:49 utm dhclient: bound to 107.A.B.C -- renewal in 298 seconds.


107.A.B.C is my public ip.

For sh!ts and giggles I tried your suggestion above.  Port numbers really don't matter but consider the following.
Plugged in as follows

Port 1 = ONT
Port 2 = wan port of RGW

Broadband light flashed for a bit then went solid.  Good sign.

My utm box already had its mac spoofed to the RGW and DHCP enabled for wan IP.  Plugged it into port 3 and quickly unplugged RGW cable from port 2.  Results below:

AFTER

Code Select Expand


2018:05:01-14:47:52 utm dhclient: Killed old client process
2018:05:01-14:47:53 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:15 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:20 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:26 utm dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
2018:05:01-14:48:26 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:26 utm dhclient: [b]DHCPOFFER from 99.137.x.y[/b]
2018:05:01-14:48:31 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:37 utm dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
2018:05:01-14:48:37 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:37 utm dhclient: [b]DHCPOFFER from 99.137.x.y[/b]
2018:05:01-14:48:43 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:55 utm dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
2018:05:01-14:48:55 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:55 utm dhclient: [b]DHCPOFFER from 99.137.x.y[/b]
2018:05:01-14:48:58 utm dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
2018:05:01-14:48:58 utm dhclient: [b]DHCPACK from 99.137.x.y[/b]
2018:05:01-14:48:58 utm dhclient: [b]bound to 107.A.B.C -- renewal in 580413 seconds.[/b]


99.137.x.y Is the next hop after 192.168.1.254 in any traceroute (through the RGW).

The whole process took about a minute to re-establish connectivity.  UTM has an option to disable/re-enable the interface.  I think it's the equivalent of ifconfig {interface} down/up command. 



The renewal interval is an odd number above.  I've performed a forced wan ip renew several times.  Each time the renewal in.... number is different.

Code Select Expand


renewal in 572429 seconds.
renewal in 568221 seconds.
renewal in 457117 seconds.
renewal in 505034 seconds.
[code]

This comes out to:
[code]
seconds days
572429 6.62
568221 6.57
457117 5.29
505034 5.84


So I guess we'll find out what happens in about a week. 

Still, this is waaaaaaaaaaaayyyyyyyyy too easy!  At this point the rgw remains unplugged and powered down.  If this continues to work like this after week 3 I will truly be impressed.  It eliminates the need for any additional hardware, scripting knowledge and other associated headaches.

Speed tests are about what they were before. Not many (any?) fiber customers in my neighborhood so full gigabit speeds are attainable most times.

As expected traceroutes no longer have the 192.168.1.254 hop.  Also, my electric bill will be a tad cheaper.  Per the UPS, consumption is down about 8 watts or about $8 a year :)

THANK YOU AGAIN!!!!

I'm going to give this a shot.. Got a netgear gs108ev3 on the way.  I am using the bgw210 gateway.  From what I've read, this (the bgw) was the gateway that some ngv598/599 customers received due to wifi issues or other reasons.  It goes to reason that att wouldn't change the authentication process just because of an upgraded gateway.

Wish me luck :)

@hutiucip

I5 5250 supports vt-d, the other one does not.  This is necessary in virtualization to allow pci passthrough.  That is direct access to peripherals rather than emulation.  Example, exsi does not allow tagged vlan 0 traffic through their network stack.  Using pci passthrough the nic can be configured for direct access by VM allowing access to full capabilities of the nic.

Worth checking how well the thermal paste was applied in Assembly
My i5 ran hot until I reapplied it. The i7 was fine

Can you clarify what you actually did.  I understood it wasn't thermal paste used but a thermal pad of some sort?  Take any pics?

Thanks!