Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 45 replies
  • Subscribers 2 subscribers
  • Views 39430 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

Configuring a VLAN across eth0, eth2 and eth3.

bloudraak_01
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.
  • 0
    Werner, I don't understand why you have bridged these three interfaces - your first post doesn't help us understand what subnets are where or why you configured this.  I agree with Jeff's first response that there must be an issue with bridging.  Why did you decide to try this?

    Cheers - Bob
  • 0
    The subnet for VLAN 13 is 172.16.13.0/24. 

    Lets step back for a moment.  I have three ESXi servers which hosts web servers, mail and some development servers [at least they did before buying the UTM device]. The physical server and virtual machines were directly connected to the internet and being attacked, consuming computer resources and my time.

    I decided to buy a Sophos UTM to act as the firewall, VPN and IPS so that administration interfaces (SSH, ESXi, Windows, OS X and Ubuntu administration) can only be accessed via the VPN. 

    I installed the virtual appliance of Sophos UTM in ESXi.  It pretty much stopped attacks against virtual machines.  When I ran some vulnerability scanners, I noticed that they effected servers I really didn't want to be attacked. In essence, it was recommended I look at VLANs.  So I did.

    However, in Sophos UTM I couldn't specify that a VLAN spanned more than one interface. So when I moved a virtual machine from interface to another, I had to reconfigure its networking, firewall etc. It had challenges. I screwed up connectivity on several occasions. Fortunately everything was virtual so I could start again. 

    When I bridged the adapters, everything started to work well. I configured 5 VLANs. I could move a machine from one interface to another and everything worked, without having to reconfigure networking etc. Some of the VLANs spanned interfaces and machines were able to communicate with each other without a problem.  Security testing was also isolated to a VLAN.  

    But my ESXi hosts were still vulnerable. I needed hardware.

    I bought the Sophos UTM with the intent to connect the three ESXi servers to eth0, eth2 and eth3, bridge the adapters and have them run in VLAN 13 (similar to the setup I had in the virtualization environment). Once I had this configured, I'll create a couple more VLANs to isolate mail servers from security lab from development servers.  

    So on Friday someone at the datacenter spent the time to hook up the ESXi servers to the Sophos UTM and configure each one to run on VLAN 13. Everything seemed fine.  We never tested communication between the ESXi servers, only from the router to the ESXi servers.

    So this morning it came as a surprise that connections are being dropped. As mentioned in previous posts, I noticed that only one server can be pinged at a time.  TCPDUMP dumps seems to confirm that.  

    Hope it makes sense.

    Werner
  • 0
    So, since this all is in an ESXi environment, why use a bridge instead of a single interface?

    If it's a bandwidth issue, then maybe it should have been a LAG instead of a bridge, and the switches should have been adjusted appropriately...

    Cheers - Bob
  • 0
    I tested it in ESXi before I bought the hardware.

    Now I have 3x ESXi Servers and 1x Sophos UTM. All physical hardware. ESXi servers are connected to eth0, eth2 and eth3. The WAN is eth1 and connected to the internet. I don't have another physical switch.  Hence the need to have the VLAN span the three interfaces.

    I had a look at LAG, but I couldn't create a VLAN on the LAG.
  • 0
    You are trying to give us the info to help you and I do appreciate that, but the format is making it a bit difficult to see what's going on. Can you also include -n in your tcpdumps so that it isn't using the names and is instead using the IP addresses, this will help as well.

    Can you try doing it in a format such as:

    Pinged from 172.16.13.2 to 172.16.13.3
    tcpdump from 172.16.13.2:
    blah blah blah blah blah

    tcpdump from 172.16.13.3:
    blah blah blah blah blah

    tcpdump from router (172.16.13.1):
    blah blah blah blah blah



    pinged 172.16.13.2 to 172.16.13.4
    tcpdump from 172.16.13.2:
    blah blah blah blah blah

    tcpdump from 172.16.13.4:
    blah blah blah blah blah

    tcpdump from router (172.16.13.1):
    blah blah blah blah blah

    Have you tried disabling virtual MACs in ESXi?
  • 0
    Sure. I'll rerun those tests.  Couple of notes

    - I'm running tcpdump-uw, which is ESXi equivalent; outputs are different.
    - At this stage I'm just piping the TCPDUMP output to a file, since the SSH (say to 172.16.13.3) connection itself "freezes" when another server (say to 172.16.13.4) has a connection. 

    Let me get on with it then...

    Thanks for the help.
  • 0
    ESXi servers are connected to eth0, eth2 and eth3

    I still think you may have a fundamental design issue.  Why should you need a bridge in the UTM?  I can't see why we're stuck with these complications...

    Cheers - Bob
  • 0
    Bob,

    Perhaps you see an answer to my original problem?

    How do I configure the same VLAN across eth0, eth2 or eth3? I do not want virtual machines in a security lab running on the ESXi hosts to get a sniff of the ESXi hosts, hence the use of a VLAN.

    Its easy to point out complications, but that doesn't bring me anywhere nearer to a solution.   

    Sincerely,
    Werner
  • 0
    Ping from 172.16.13.3 to 172.16.13.2 with 100% packet loss.

    tcpdump from 172.16.13.3:
    05:17:08.955013 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:17:08.955137 ARP, Reply 172.16.13.3 is-at a8:20:66:31:f8:30, length 28
    05:17:20.280858 ARP, Request who-has 172.16.13.2 tell 172.16.13.3, length 28
    05:17:21.282909 ARP, Request who-has 172.16.13.2 tell 172.16.13.3, length 28
    05:17:22.284043 ARP, Request who-has 172.16.13.2 tell 172.16.13.3, length 28
    05:17:41.543730 ARP, Request who-has 172.16.13.2 tell 172.16.13.1, length 42
    05:18:02.261793 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:18:02.261824 ARP, Reply 172.16.13.3 is-at a8:20:66:31:f8:30, length 28

    tcpdump from 172.16.13.2
    05:15:43.336702 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:15:44.336721 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:15:45.336735 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:15:47.192515 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:15:47.390222 ARP, Request who-has 172.16.13.4 tell 172.16.13.1, length 42
    05:16:37.917590 ARP, Request who-has 172.16.13.3 tell 172.16.13.1, length 42
    05:17:48.087358 ARP, Request who-has 172.16.13.2 tell 172.16.13.1, length 42
    05:17:48.087394 ARP, Reply 172.16.13.2 is-at a8:20:66:31:f8:30, length 28

    tcpdump from router (172.16.13.1)
    22:16:53.167626 arp who-has 172.16.13.3 tell 172.16.13.1
    22:16:53.167896 arp reply 172.16.13.3 is-at a8:20:66:31:f8:30
    22:17:04.493611 arp who-has 172.16.13.2 tell 172.16.13.3
    22:17:05.495626 arp who-has 172.16.13.2 tell 172.16.13.3
    22:17:06.496692 arp who-has 172.16.13.2 tell 172.16.13.3
    22:17:25.755600 arp who-has 172.16.13.2 tell 172.16.13.1
    22:17:25.755934 arp reply 172.16.13.2 is-at a8:20:66:31:f8:30

    tcpdump command ran on 172.16.13.2 and 172.16.13.3
    tcpdump-uw -n -i vmk0 not tcp port 22 or tcp port 443 > dump.txt

    tcpdump command ran on the router
    tcpdump -n -i br0.13 -s0 not tcp port 22 or tcp port 443
  • 0
    Ping from 172.16.13.3 to 8.8.8.8 with no packet loss.

    tcpdump from 172.16.13.3:
    05:23:35.662937 IP truncated-ip - 2 bytes missing! 172.16.13.3 > 8.8.8.8: ICMP echo request, id 17469, seq 0, length 64
    05:23:35.697740 IP truncated-ip - 2 bytes missing! 8.8.8.8 > 172.16.13.3: ICMP echo reply, id 17469, seq 0, length 64
    05:23:36.664985 IP truncated-ip - 2 bytes missing! 172.16.13.3 > 8.8.8.8: ICMP echo request, id 17469, seq 1, length 64
    05:23:36.699730 IP truncated-ip - 2 bytes missing! 8.8.8.8 > 172.16.13.3: ICMP echo reply, id 17469, seq 1, length 64
    05:23:37.667036 IP truncated-ip - 2 bytes missing! 172.16.13.3 > 8.8.8.8: ICMP echo request, id 17469, seq 2, length 64
    05:23:37.701663 IP truncated-ip - 2 bytes missing! 8.8.8.8 > 172.16.13.3: ICMP echo reply, id 17469, seq 2, length 64

    tcpdump from router (172.16.13.1)
    22:23:13.823635 arp who-has 172.16.13.3 tell 172.16.13.1
    22:23:13.823827 arp reply 172.16.13.3 is-at a8:20:66:31:f8:30
    22:23:19.868919 IP 172.16.13.3 > 8.8.8.8: ICMP echo request, id 17469, seq 0, length 64
    22:23:19.903314 IP 8.8.8.8 > 172.16.13.3: ICMP echo reply, id 17469, seq 0, length 64
    22:23:20.870878 IP 172.16.13.3 > 8.8.8.8: ICMP echo request, id 17469, seq 1, length 64
    22:23:20.905284 IP 8.8.8.8 > 172.16.13.3: ICMP echo reply, id 17469, seq 1, length 64
    22:23:21.872907 IP 172.16.13.3 > 8.8.8.8: ICMP echo request, id 17469, seq 2, length 64
    22:23:21.907206 IP 8.8.8.8 > 172.16.13.3: ICMP echo reply, id 17469, seq 2, length 64

    tcpdump command ran on 172.16.13.3
    tcpdump-uw -n -i vmk0 not tcp port 22 or tcp port 443 > dump.txt

    tcpdump command ran on the router
    tcpdump -n -i br0.13 -s0 not tcp port 22 or tcp port 443