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

Local network unreachable when Bridging enabled

I just started to use the Sophos UTM for my home network. 

First I will explain my environment, so you have some background information.
I have a single server at my home, which is running ESXi 5.1.0, 1743533. This server contains 3 network cards, each for a single virtual network.

NIC0 my WAN connection
NIC1 my LAN1 connection
NIC2 my LAN2 connection

With my previous firewall, pfSense, both LAN NIC's where configured as a bridge. So I could use them both for my single lan network. All the 3 networks have the promisicuous mode set to accept, within the vSwitch configuration.
This worked fine with pfSense.

Sophos UTM is running inside a virtual machine on this server and is connected with all of the 3 networks.

This setup worked fine with the use of a single LANx network:
ETH0 is connected to LAN1 with a static IP of x.x.1.254
ETH1 is connected to WAN with a dynamic IP
ETH2 is connected to LAN2 not configured

At the moment I make a bridge between ETH0 and ETH2 inside Sophos UTM, I'm not be able to access some webpages inside my home network (running on different VM's), also the vSphere client isn't be able to connect to the server. But access to the internet from LAN1 and LAN2 is working fine.

I first thought that the firewall was blocking the traffic, so I created a new firewall rule for any (source) any (service) any (destination), but this didn't solve the issue. The traffic to these VM's shouldn't need to pass trough the bridge, so it would be strange if this was the solution.

When I disable the bridge, everything is working fine again. (except the LAN2 connection).
Do I missed some configuration settings of the Sophos UTM to make the bridge working fine? Please ask me if you need more information about my current setup.

Sorry for some grammar mistakes in this post, but English isn't my native language.


This thread was automatically locked due to age.
  • Were you able to get this fixed.  I am having the exact same issue.

    Thanks,

    Matt
  • Matt, try #1 in Rulz.  Any luck with that?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Matt, I still have this issue. I will try #1 in Rulz to see if I see anything strange in those log files.

    Update:
    The application log and Instrusion Prevention System log is complete empty. The firewall showed me an UDP request at my external wan address UDP port 1, at the moment I try to logon to ESXi.


    12:06:00 Default DROP UDP  
    61.3.202.123 : 36963

    (wan ip): 1
     
    len=48 ttl=114 tos=0x00 srcmac=0:1b[:D]5:fe:ca[:D]9 dstmac=0:c:29:21:3a:57
    12:06:06 Default DROP UDP  
    61.3.202.123 : 36963

    (wan ip): 1
     
    len=48 ttl=114 tos=0x00 srcmac=0:1b[:D]5:fe:ca[:D]9 dstmac=0:c:29:21:3a:57



    Update 2:
    If I open the log of the VMware ESXi there is one message:
    the underlying connection was closed an unexpected error occurred on a receive is a English translation of "De onderliggende verbinding is gesloten: Bij verzending is een onverwachte fout opgetreden".
    [        :Error   :M: 1] 2014-08-15 12:05:56.166  Error retrieving clients.xml
    Exception already logged, summary: System.Net.WebException:The client could not send a complete request to the server. (De onderliggende verbinding is gesloten: Bij verzending is een onverwachte fout opgetreden.)
    [        :QuickInf:W: 8] 2014-08-15 12:13:54.200  Set the dll search path to C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\5.1
    [        :QuickInf:W: 8] 2014-08-15 12:13:54.612  Load Shared DLLs: C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\5.1
    [        :startup :W: 8] 2014-08-15 12:13:56.262  Log for vSphere Client, pid=1968, version=5.1.0, build=build-1471691, option=release, user=root, url = https://192.168.1.240/sdk
    [viclient:SoapTran:W: 8] 2014-08-15 12:13:57.830  Invoke 1 Start RetrieveContent on ServiceInstance:ServiceInstance [192.168.1.240]. [operationID:009C88E0-00000001][Caller: VmomiSupport.VcServiceImpl.InitializeTransport]
    [viclient:SrvMsg  :W: 8] 2014-08-15 12:13:58.943  RMI Request Vmomi.ServiceInstance.RetrieveContent - 1
    [viclient:Critical[[[[[[[:P]]]]]]]:14] 2014-08-15 12:13:59.230  Connection State[192.168.1.240]: Connected
    [viclient:SoapTran:W: 8] 2014-08-15 12:13:59.234  Invoke 1 Finish RetrieveContent on ServiceInstance:ServiceInstance [192.168.1.240] - Serial:1,134, Server:000,245
    [viclient:SoapTran:W: 8] 2014-08-15 12:13:59.235  Invoke 2 Start RetrieveInternalContent on ServiceInstance:ServiceInstance [192.168.1.240]. [operationID:009C88E0-00000002][Caller: VmomiSupport.VcServiceImpl.InitializeTransport]
    [viclient:SrvMsg  :W: 8] 2014-08-15 12:13:59.235  RMI Request Vmomi.ServiceInstance.RetrieveInternalContent - 2
    [viclient:SoapTran:W: 8] 2014-08-15 12:13:59.247  Invoke 2 Finish RetrieveInternalContent on ServiceInstance:ServiceInstance [192.168.1.240] - Serial:0,006, Server:000,006
    [        :VmrcInfo:W: 8] 2014-08-15 12:13:59.353  VMRC guid is 4aea1010-0a0c-405e-9b74-767fc8a998cb
    [        :VmrcInfo:W: 8] 2014-08-15 12:13:59.354  VMRC InProcSrv32 is C:\Program Files (x86)\Common Files\VMware\VMware Remote Console Plug-in 5.1\Internet Explorer\vmwareRemoteConsole.dll
    [        :VmrcInfo:W: 8] 2014-08-15 12:13:59.472  vmwareRemoteConsole.dll: FileVersion=5.1.0.1465558 ProductVersion=5.1.0.1465558 (Private=30364) Engels (Verenigde Staten) 
    Created=2013-12-06T12:30:04 Written=2013-12-06T12:30:04 Size=533720 bytes
    [        :VmrcInfo:W: 8] 2014-08-15 12:13:59.590  vmware-vmrc.exe: FileVersion=e.x.p build-1465558 ProductVersion=e.x.p build-1465558 (Private=30364) Engels (Verenigde Staten) 
    Created=2013-12-06T12:30:04 Written=2013-12-06T12:30:04 Size=2717400 bytes
    [        :VmrcInfo:W: 8] 2014-08-15 12:13:59.591  Interop.VMwareRemoteConsoleTypeLib.dll: FileVersion=5.1.0.0 ProductVersion=5.1.0.0 (Private=0) Invariante taal (Invariant(e) land/regio)  
    Created=2013-12-10T02:06:22 Written=2013-12-10T02:06:22 Size=40664 bytes
    [        :VmrcInfo:W: 8] 2014-08-15 12:13:59.662  AxInterop.VMwareRemoteConsoleTypeLib.dll: FileVersion=5.1.0.0 ProductVersion=5.1.0.0 (Private=0) Taalonafhankelijk 
    Created=2013-12-10T02:05:58 Written=2013-12-10T02:05:58 Size=23256 bytes
    [        :QuickInf:W: 8] 2014-08-15 12:13:59.669  (VIClient, Version=5.1.0.1, Culture=neutral, PublicKeyToken=7c80a434483c7c50) VpxClientCommon.Utils.HelpServiceImpl -> VpxClientCommon.Util.HelpServiceImpl
    [        [[[[[[[:P]]]]]]]erfInfo:W: 8] 2014-08-15 12:13:59.681  [Hndl:GDI=42][Hndl:User=47][Hndl:Kernel=718][Mem:WS=68804608 (65.62 MB)][Mem:VirtualUsed=356151296 (339.65 MB)][Mem[[[[[[[:P]]]]]]]rivateUsed=53157888 (50.70 MB)][Mem:NETUsed=6139624 (5.86 MB)][Mem[[[[[[[:P]]]]]]]F=53157888 (50.70 MB)][Mem[[[[[[[:P]]]]]]]agedUsed=554608 (541.61 KB)][Mem:NonPagedUsed=102344 (99.95 KB)][CPU:Threads=21][CPU:Total=00:00:04.7031250][CPU:User=00:00:03.5937500][CPU:Kernel=00:00:01.1093750]
    [        :QuickInf:W:15] 2014-08-15 12:14:00.189  Checking memory : 78643200 bytes required, 4152741888 available.
    [VICnMngt:Critical:W: 8] 2014-08-15 12:14:00.193  Constructor subscribe to https://192.168.1.240/sdk
    [viclient:SoapTran[[[[[[[:P]]]]]]]: 4] 2014-08-15 12:14:00.216  Invoke 3 Start Login on SessionManager:ha-sessionmgr [192.168.1.240]. [operationID:009C88E0-00000003][Caller: VmomiSupport.VcServiceImpl.LoginNormally]
    [viclient:SrvMsg  [[[[[[[:P]]]]]]]: 4] 2014-08-15 12:14:00.228  RMI Request Vmomi.SessionManager.Login - 3


    Inside the configuration of this management network inside ESXi it showed the MAC address of a physical interface. This is correct because the management netwerk is using the same NIC as used for my VM's, like Sophos. I think there's something happening with the MAC address of the interfaces in Sophos at the moment I create the bridge....

    Update 3:
    A quick overview of the MAC addresses between Sophos and a working bridged setup in pfSense:
    pfSense showed me those MAC addresses after the bridge is created:

    LAN1:
    MAC address 00:0c:29:7e:6e:38
    IPv6 Link Local fe80::20c:29ff:fe7e:6e38%em1  
    Bridge (bridge0) learning

    LAN2:
    MAC address 00:0c:29:7e:6e:42
    IPv6 Link Local fe80::20c:29ff:fe7e:6e42%em2  
    Bridge (bridge0) learning

    Bridge (LAN1 + LAN2):
    MAC address 02:ac:56[:D]1:88:00
    IPv4 address 192.168.1.251  
    Subnet mask IPv4 255.255.255.0


    In Sophos I found this information:
    LAN1:
    eth0 Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
    MAC Address: 00:0c:29:21:3a:4d
    Interrupt (IRQ): 18
    PCI Device ID: 0x100f:0x750
    MII capable: No

    LAN2:
    eth2 Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
    MAC Address: 00:0c:29:21:3a:61
    Interrupt (IRQ): 17
    PCI Device ID: 0x100f:0x750
    MII capable: No

    Bridge (eth0 + eth2):
    Vitual MAC: 00:0c:29:21:3a:4d

    So it suspect it's related that the virtual mac of the bridge in Sophos is the same mac as the physical mac address of eth0. Is it safe to change the virtual mac address, and which address will be fine to use? Should this be something in the 02:ac: range (because pfSense has also a specific different range)??
  • So I was able to get mine working. I figured out that it was the web protection that was blocking the http / https traffic to my local LAN machines. I added my Internal LAN Network to "Skip transparent mode destination hosts/nets" in the filtering options - misc tab and I can access my network again.

    Hope this helps.
  • So I was able to get mine working. I figured out that it was the web protection that was blocking the http / https traffic to my local LAN machines. I added my Internal LAN Network to "Skip transparent mode destination hosts/nets" in the filtering options - misc tab and I can access my network again.

    Hope this helps.


    Thanks, this also resolved my connection issues!