Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 4 subscribers
  • Views 5445 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Controlling Traffic with Bridged Interfaces

Jay Jay

I'm trying to gain clarity in understanding how UTM treats an interface bridge.  Lets says say two interfaces, eth2 and eth3 are bridged.

1) That means without any additional rules, regular tcp/udp traffic will be allowed to pass through from eth2 to/from eth3?

2) Utm automatically adds an ethertype of 88b7. I couldn't find much information on this protocol other than it's an IEEE Std 802 - OUI Extended Ethertype.  What uses this ethertype?

3) It appears once two interfaces are bridged, direct access to each child interface is no longer available (at least not through webadmin).

4) Lets assume a firewall rule is created that permits all traffic from the lan network to/from the bridge.  That means this traffic will pass to/from child interfaces to the lan?

5) I understand custom ethertypes can be defined in the bridge setting to be forwarded. Does this mean forwarded between bridge child interfaces or between the bridge and other interfaces (such as local lan). 

 

Here's more context for these questions.

I recently had att fiber internet installed.  Their installation consists of running fiber to a box on the side of the premises. From there another length of fiber is run inside to the ONT (optical network terminal).  This converts fiber to ethernet. The ONT connects via ethernet to an att provided residential gateway (RGW) which authenticates the connection and provides routing functions.

Of course the goal is to eliminate or minimize the gateway so that a pure unfiltered internet connection is available to the UTM.  Similar to how it was with my owned modem when I had cable internet.

I've achieved this to some extent by doing the following.  The ONT and RGW wan ports are connected to a basic unmanaged switch.  After less than a minute, the broadband light is solid green on the RGW indicating internet is available.  The RGW's cable is unplugged from the switch and replaced with UTM WAN interface cable.  Earlier UTM's wan interface mac address was spoofed to that of the RGW. IP acquisition is set to dhcp. After about a minute or so UTM acquires the public IP and gateway from att's dhcp server and has internet connectivity.  Lease time is 14 days, with a renewal attempt to take place in 7 days.  With the RGW's wan unplugged, the RGW itself serves no useful function and is powered off until one of the actions below happens.

Several actions can break the ONT's authentication which results in no internet access.

* ONT power failure
* dumb switch power failure
* disconnecting ONT's ethernet cable from either end
* dhcp lease not renewed successfully within 14 days
* att attempting to push a firmware upgrade
* other factors not considered

The authentication process between the ONT and RGW is by EAPOL 802.1x.  This involves ethertype 888e traffic between the two.

Goal:  To eliminate the use of the dumb switch.  Instead, to configure UTM (which runs on a box with 4 nics) to allow only EAPOL traffic between the RGW and ONT while passing all other internet traffic between the LAN and ONT. This way should an event occur requiring reauthentication, it's just a matter of powering the RGW on to let it do it's thing then power off once done.



This thread was automatically locked due to age.
Parents
  • 0

    The official Ethertype list is maintained by IANA.   Just do a web search for "Ethertype List" and follow the link for iana.org

    A bridged interface acts like a switch (layer 2), except that it filters traffic that a normal switch would allow.   That is why you need to know what Ethertypes will be needed and enable them.

    My opinion is that UTM should not be used as a bridge for internal traffic, as it is not optimized for that purpose.   Bridge mode makes sense to me only when you want to insert UTM in-line behind an existing firewall, rather than having UTM be your firewall.

    All UTM interfaces (e.g. A0 and A1) are virtualizations of the hardware interfaces (e.g ETH0 and ETH1).   A bridge is a virtualization of multiple hardware interfaces into one UTM interface.   Consequently, you cannot address the members individually at the UTM level, as there is no object to do so.

    All traffic between UTM interfaces is handled as layer 3, with either routing for unfiltered traffic or capture-and-retransmit for proxied traffic.   Ethertype is a layer 2 concept, so Ethertyp forwarding or filtering only applies at Layer 2 - between the components of your bridged interface.

    For your configuration, I don't know why the ISP connection needs to terminate in the dumb switch.   It should be able to terminate into UTM.   That is the issue you need to investigate.

     

     

Reply
  • 0

    The official Ethertype list is maintained by IANA.   Just do a web search for "Ethertype List" and follow the link for iana.org

    A bridged interface acts like a switch (layer 2), except that it filters traffic that a normal switch would allow.   That is why you need to know what Ethertypes will be needed and enable them.

    My opinion is that UTM should not be used as a bridge for internal traffic, as it is not optimized for that purpose.   Bridge mode makes sense to me only when you want to insert UTM in-line behind an existing firewall, rather than having UTM be your firewall.

    All UTM interfaces (e.g. A0 and A1) are virtualizations of the hardware interfaces (e.g ETH0 and ETH1).   A bridge is a virtualization of multiple hardware interfaces into one UTM interface.   Consequently, you cannot address the members individually at the UTM level, as there is no object to do so.

    All traffic between UTM interfaces is handled as layer 3, with either routing for unfiltered traffic or capture-and-retransmit for proxied traffic.   Ethertype is a layer 2 concept, so Ethertyp forwarding or filtering only applies at Layer 2 - between the components of your bridged interface.

    For your configuration, I don't know why the ISP connection needs to terminate in the dumb switch.   It should be able to terminate into UTM.   That is the issue you need to investigate.

     

     

Children
  • 0 in reply to DouglasFoster

    Douglas,

    Thanks for the bridging function explanation.

    For your configuration, I don't know why the ISP connection needs to terminate in the dumb switch.   It should be able to terminate into UTM.   That is the issue you need to investigate.

    I thought I explained this in the context section of the initial post.  I agree, it should terminate into the UTM, but due to the authentication only the RGW can provide, it can't terminate directly.  That's what I'm trying to achieve - some means to permit EAPOL only traffic between the ONT and RGW by the UTM.  This would satisfy the authentication need but actual internet traffic would go between the ONT<>UTM.  In the course of my research, at&t has been using this method with fiber for a number of years.  Same for their vdsl connections, but due to vastly different technologies, the modem must stay remain in the vdsl type service. With fiber, since the wan from the ONT is already ethernet, a pseudo bypass is possible.

    I haven't tried this yet, but I think bridging the ONT/RGW interfaces with ethertype 888e would work as far as allow the RGW to authenticate the ONT.  But, if I masquerade lan traffic to the bridge it would flood both the ONT and RGW (assuming the RGW is on).  I wonder if this could still be achieved by simply unplugged/powering the RGW down once it's served the purpose of authenticating the ONT.  This is easy to test.  Will report back.

Unfiltered HTML