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

Configuring a VLAN across eth0, eth2 and eth3.

Hello,

I have a Sophos UTM 110 with devices connected to eth0, eth2 and eth3. The devices are configured to use VLAN 13. I found that I had to bridge eth0, eth2 and eth3 in order to allow the devices connected to those interfaces communicate using VLAN 13. 

Note that the devices are hypervisors (ESXi) and virtual machines running inside of them will be communicating on a different VLAN. This allows me to use the ESXi servers for a security testing without worrying that the malicious software can undermine my ESXi hosts, or other virtual machines hosting web sites etc.

So here's the steps I took:

[LIST=1]
  •  Got the Sophos UTM 110 device (aka router)
  •  Configured public IPv4 address and verified I can connect to WebAdmin over eth1. 
  •  Bridged eth0, eth2 and eth3
  •  Configured a VLAN 13 on br0, named Orion (aka the Constellation)
  •  Configured L2TP VPN 
  •  Added firewall rule to allow all traffic from VPN Pool (L2TP) to the Orion Network (aka VLAN 13)
  •  Defined a DHCP server for the Orion Network (aka VLAN 13)
  •  Connected servers to router configured to use DHCP and VLAN 13.
  •  Servers reporting DHCP errors, sometimes getting an IP, but often reporting issues.
  •  Configured server to use static IP addresses 172.16.13.2, 172.16.13.3 and 172.16.13.4. 
  •  Verify connection works by pining each server from router. This was done in parallel. Everything seemed ok.
  •  At home configure L2TP VPN on OS X 10.8.3.
  •  Connect to Sophos UTM 110 using VPN on OS X from home.
  •  Connect to servers over VPN from home.  Intermittent issues; connection timeouts and disconnected when working on multiple machines at the same time.
  •  Open three terminal windows in OS X 10.8.3 and ping 172.16.13.2, 172.16.13.3 and 172.16.13.4 in parallel.  Seems I can only ping to one device at a time, the other time out [Request timeout for icmp_seq 739]. Leaving it running for a while indicates that if ping works for one server, it fails for the other two. Every now and then, ping will start working for another server and then timeout on the one where it worked.
  • SSH into each server (problematic due to intermitted disconnects)
  • From within the SSH session, ping another server. Ping fails.
  • From within the SSH session, ping router. Ping succeeds.
[/LIST]

At this stage, no traffic to the internet is permitted, so I didn't even bother to ping Google or another external site.  

Questions:
[LIST=1]
  • Is creating a bridge to support a VLAN across eth0, eth2 and eth3 the right way to do this?  It would have been easier if I could just specify the "Orion Network" to be spanning eth0, eth2 and eth3 like some other routers. But it doesn't seem to be possible using Sophos UTM.
  • If creating a bridge is the right way to achieve this, is there something I'm missing configuration wise that prevents all three devices from being accessed at the same time (aka ping all 3 without time outs)
  • If creating a bridge isn't the right way to achieve this, then how does one support a VLAN across multiple interfaces?
[/LIST]

I know that usually one will connect another switch to eth0 which takes care of the VLAN, but at this stage I do not have enough space at the data centre to add another switch. In essence, I was hoping the Sophos UTM would be sufficient. 

Sincerely,
Werner


This thread was automatically locked due to age.
  • Hi Bob,

    The Sophos UTM is the only switch/router/firewall/gateway I'm using at the data centre. There is no other.  That is why the three ESXi hosts are connected to eth0, eth2 and eth3. Usually folks will have another switch to which they will connect the ESXi hosts and connect that switch to eth0. In that case, you can define several VLANs on eth0 and everything is pretty simple and there is no need for a bridge. However, I don't have space at the data centre for another switch and I don't want to pay for space.   

    However, in Sophos UTM, it seems one can have many VLANs per interface, but its much more complex to configure multiple interfaces (eth0, eth2 and eth3) per VLAN. It complicates the overall configuration including DHCP servers, NAT, firewall etc.

    Bridging the thee interfaces (eth0, eth2 and eth3) into one (br0), makes VLAN configuration much simpler.  Just consider how you'll span VLAN across eth0, eth2 and eth3 without bridging, while still having a DHCP for that VLAN,  NAT and firewall rules.

    I hope it makes sense. 

    Sincerely,
    Werner
  • 1) If you edit that bridge interface and you turn on ProxyARP, is there still no love?

    2) If there is still no love, can you try taking another tcpdump just like the first one?  I'm wondering if it will look different now that we've fixed the problem of many machines having one MAC.
  • Is there anything that prevents communication between devices on the same bridge?

    I believe that there are bugs in V9 related to bridging.  I have a client in Costa Rica that has had random issues that Support cannot explain.  It's one of the reasons I've persisted about questionning your use of a bridge.  I understand your situation, but not why you can't create a virtual switch in ESXi to solve the problem...

    Cheers - Bob
  • Hi Bob, it's because he has multiple VM SERVERS and no switch.

    If it were me, I'd consider putting each server in a different network instead of bridging, but that could hamper VM Migrations.

    I would also consider getting a compact switch and making it fit, perhaps next to a PDU if there is no rack space.

    Barry

  • However, I'm unable to SSH from one ESXi server [172.16.13.10] to another [172.16.13.11 and 172.16.13.12]. Or from [172.16.13.12] to the others [172.16.13.11 or 172.16.13.10]. In essence, the connection times out. 

    Is there anything that prevents communication between devices on the same bridge? 


    Hi, check the logs if you haven't already (Firewall, IPS).

    If they don't show anything, run tcpdump on each interface on the firewall.

    Barry