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

Validating inter-VLAN routing on UTM9

Hello Sophos Community,

Is there a way to validate inter-VLAN routing on a UTM9 appliance? Our network is setup using 5 or 6 different VLANs and everything has been working great and as expected for the past few years. Recently, I created a new VLAN (ID: 20) interface for a new VoIP phone system. I have added the VLAN interface under Interfaces & Routing -> Interfaces; assigning the correct new VLAN tag (20), IPv4 address, and selected the lag0 trunk we have already in-place for the existing VLANs.

I am unable to traceroute to hosts on the new VLAN from my workstation computer, which is on one of the prior existing VLANs (ID: 1). There is already an existing firewall rule that allows traffic from my workstation VLAN on any service to any destination, and I am able to traceroute to hosts between the prior existing VLANs. The VoIP phone system on VLAN 20 is able to connect to the internet (ie. it can ping 8.8.8.8) so I believe I have the managed switches configured properly.

I'm wanting to rule out that I have done the proper configuration on the Sophos UTM9 appliance to setup and allow inter-VLAN routing between my old VLAN (ID: 2) and newly created VLAN (ID: 20). In reading a few prior posts in these forums, I'm lead to believe that when setting up the new interface the UTM should automatically be adding any necessary configuration to allow inter-VLAN routing (provided that there is a firewall rule allowing from one network to the other, which I have).

Can anyone offer any advice here on what I may be missing?

Thanks in advance!



This thread was automatically locked due to age.
Parents
  • Hello  ,

    Good day and thanks for reaching out to Sophos Community. 

    do you use L2 (router on a stick) or L3 switch (routed) -> UTM?

    Also, can you reach endpoints on VLAN20 when you try to ping it from the Firewall? 

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Hi Raphael,

    Thank you for the response. We have a few different Layer3 switches in place; below is a crude topology diagram of the network.

    Yes I am able to successfully ping the VoIP Phone System from the UTM ping tool under Support -> Tools. ( 0% packet loss ) The VoIP Phone System is also able to reach the internet and successfully make & receive calls.

    In the diagram above; from Workstation 1 (VLAN ID: 1), I am able to traceroute to and access hosts on other prior existing vlans (ie. VLAN ID: 6, or VLAN ID: 4)

    I just cannot traceroute or access any hosts on the newly created VLAN ID: 20.

  • The full routing table can be found under "Support / Erweitert / Routen" (or the equivalent in the chosen language).

    Don't be afraid it's huge, but is Linux' iproute2 after all. You should see routes to the IP ranges of the relevant VLAN interfaces (didn't find these in your picture) but it might look similar to:

    default via 192.168.1.254 dev lag0.1 table default  proto kernel  metric 20 onlink 
    127.0.0.0/8 dev lo  scope link
    192.168.1.0/24 dev lag0.1 proto kernel scope link src 192.168.1.1
    192.168.4.0/24 dev lag0.4 proto kernel scope link src 192.168.4.1
    (...)
    192.168.20.0/24 dev lag0.20 proto kernel scope link src 192.168.20.1

    If VLAN 20 is there - good, otherwise you might check the interface configuration.

    Next check might be "Support / Tools / Ping" (or "/ Traceroute").

    Select the VLAN20 interface (last point, "Über Schnittstelle pingen") and the IP of a node in the VLAN 20 known to be reachable.

    If there is no response you might check the Config of your Netgear switch setup for handling of the VLAN 20.

    Third point to look at is the firewall, go to "Network Protection / Firewall /Live protocol" (it opens in a separate window) if ping packets are marked red and you see no response check your firewall setting. The rule number should be given, if it's listed as "default" you might have missed creating the appropriate rule.

Reply
  • The full routing table can be found under "Support / Erweitert / Routen" (or the equivalent in the chosen language).

    Don't be afraid it's huge, but is Linux' iproute2 after all. You should see routes to the IP ranges of the relevant VLAN interfaces (didn't find these in your picture) but it might look similar to:

    default via 192.168.1.254 dev lag0.1 table default  proto kernel  metric 20 onlink 
    127.0.0.0/8 dev lo  scope link
    192.168.1.0/24 dev lag0.1 proto kernel scope link src 192.168.1.1
    192.168.4.0/24 dev lag0.4 proto kernel scope link src 192.168.4.1
    (...)
    192.168.20.0/24 dev lag0.20 proto kernel scope link src 192.168.20.1

    If VLAN 20 is there - good, otherwise you might check the interface configuration.

    Next check might be "Support / Tools / Ping" (or "/ Traceroute").

    Select the VLAN20 interface (last point, "Über Schnittstelle pingen") and the IP of a node in the VLAN 20 known to be reachable.

    If there is no response you might check the Config of your Netgear switch setup for handling of the VLAN 20.

    Third point to look at is the firewall, go to "Network Protection / Firewall /Live protocol" (it opens in a separate window) if ping packets are marked red and you see no response check your firewall setting. The rule number should be given, if it's listed as "default" you might have missed creating the appropriate rule.

Children
  • Hi Alan,

    Thanks for the response.  I did find some relevant lines in the Routes Table (although I admit, I'm not sure if they are correct or not?)

    (...)
    192.168.3.0/24 dev lag0.20 proto kernel scope link src 192.168.3.254
    (...)
    broadcast 192.168.3.0 dev lag0.20 table local proto kernel scope link src 192.168.3.254
    local 192.168.3.254 dev lag0.20 table local proto kernel scope host src 192.168.3.254
    broadcast 192.168.3.255 dev lag0.20 table local proto kernel scope link src 192.168.3.254
    (...)

    I tried the Ping & Traceroute from the UTM also - they both worked fine.

    There is also a firewall rule defined that says traffic from the VLAN ID:1 subnet can access any/all of the other VLAN subnets defined (ie. including VLAN ID: 20)

  • Also backwards (from VLAN20 to VLAN1)?

    Maybe there is a global ping/traceroute block under Network Protection /  Firewall / ICMP?

  • I checked on that - the UTM is configured to allow pings and traceroutes.  Also, the backwards connection from VLAN20 to VLAN1 is blocked by firewall rules, but that shouldn't stop any connections from VLAN1 to VLAN20 as I'm trying.

    I can successfully ping & traceroute from the UTM itself to the VoIP System.  I think my next check here will be to try a different workstation on VLAN1, connecting to VLAN20... everything looks to be setup correctly on the UTM.

  • The "VOIP-System" needs to know how to reach your PC on VLAN1 So it must have 192.168.3.254 as either the default gateway or a special gateway route for the 192.168.1.0/24 of VLAN1. Works best if the UTM hands out IP information via DHCP.

  • Hey Alan,

    Oh yes, the VoIP System is configured to have 192.168.3.254 as its default gateway.  We have just blocked any initiated traffic (via Firewall rules on the UTM) from VLAN20 to VLAN1.  VLAN1 is on static IPs, and VLAN20 is served IPs from the DHCP service on VoIP System itself (its own IP is statically assigned on the 192.168.3. subnet, using 192.168.3.254 as default gateway).

  • So after more testing on our end here, I found that other workstation hosts on VLAN 1 are able to access the VoIP Server on VLAN 20 ... there must be something going on with my particular work station here or the path from my workstation out to VLAN 20.  From what I can tell by the other hosts' ability to connect, the UTM has properly setup the inter-VLAN routing between VLAN 1 and VLAN 20.

    Thank you Alan and Raphael for your posts in providing assistance!

  • Hello,

    Thank you for taking the time to update the thread and glad that it has worked for you now.

    Have a great rest of your day and thank you for choosing Sophos.

    Cheers,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.