Handling Tagged vlan packets

In the current version of UTM firmware, yes, you have to configure your UTM port(s) as "trunk" ports if you wish to carry more than 1 VLAN on the same interface -- all VLANs configured as tagged.  In 9.3 (currently in beta) they have enabled "hybrid" setups, where one untagged VLAN can be defined along with multiple tagged VLANs, just as you can do with most switches and routers.

So I've looked at the interfaces and can only single VLANs that can be configured, it can't see how to create a trunk.  I need an enterprise vlan that spans several UTMs, so how would I pass vlan (99)on eth3(10.0.17.x) to eth4(172.16.18.x)?

I need to keep the existing UTM config for routing various subnets for different departments, but I need a plantwide LAN via the same infrastructure, hence, the vlan. To me it seems I would need to bridge if I wanted tagged vlan traffic to egress the UTM?

how would I pass vlan (99)on eth3(10.0.17.x) to eth4(172.16.18.x)?

WebAdmin automatically creates routes for all networks defined on its interfaces and in VPNs, but you have to make firewall rules allowing the traffic.  If you find that you need a masq rule from one LAN to another, you likely have violated #3 in Rulz.

I don't think you need bridging, but I don't know what the before and after look like.  Do you have diagrams?

Cheers - Bob

Hi,

Are you planning to use the same network (for example 172.16.1.0/24) across several different sites ?

Hi,

Are you planning to use the same network (for example 172.16.1.0/24) across several different sites ?

That's the general idea, I want to span 172.16.99.x over the existing infrastructure.  I would normally use routing, however, our application uses DCOM and I can't route that protocol. hence the spanned vlan.

Is such a configuration possible with Sophos, or do I need to install additional hardware to establish a enterprise wide LAN?

Hi,

I haven't work with RED at all but it might work (not sure). But the best way to achieve something like this is EoMPLS or VPLS over GRE. But instead of wasting your time sorting out a network issue of DCOM, why not just sort out DCOM, much cheaper and more secure.

I'm still not comfortable that I can "see" your situation and where you want to go, but RED would work if these are physically-separated sites.  The Remote Ethernet Device connection is, in essence, a long Ethernet cable.  See my coach story.  For more discussion that might help you, read Routing the same subnet accross vpn.

Connect each of the less-powerful UTMs to the most-powerful UTM with a RED tunnel.  In the main site, bridge all of the red# interfaces to a physical NIC and add the 172.16.99.x VLAN to br0.  In each remote site, bridge the red0 interface to a physical NIC - I can't remember now, but I don't think you have to add the 172.16.99.x VLAN to br0 in the remote sites.  Be careful to have only a single DHCP server for this subnet, and to consider my comments in Post #4 above.

You can't create a bridge on a VLANed interface, but you can create a VLAN on a bridged interface.

Is that where you wanted to go?

Cheers - Bob

Hi,

I haven't work with RED at all but it might work (not sure). But the best way to achieve something like this is EoMPLS or VPLS over GRE. But instead of wasting your time sorting out a network issue of DCOM, why not just sort out DCOM, much cheaper and more secure.

I'd love to get away from DCOM, but it isn't my choice, the application vendor doesn't have anything else.  There is talk of OPC UA, but that is a separate can of worms with an unproven protocol. [:O]

I'm still not comfortable that I can "see" your situation and where you want to go, but RED would work if these are physically-separated sites.  The Remote Ethernet Device connection is, in essence, a long Ethernet cable.  See my coach story.  For more discussion that might help you, read Routing the same subnet accross vpn.

Connect each of the less-powerful UTMs to the most-powerful UTM with a RED tunnel.  In the main site, bridge all of the red# interfaces to a physical NIC and add the 172.16.99.x VLAN to br0.  In each remote site, bridge the red0 interface to a physical NIC - I can't remember now, but I don't think you have to add the 172.16.99.x VLAN to br0 in the remote sites.  Be careful to have only a single DHCP server for this subnet, and to consider my comments in Post #4 above.

You can't create a bridge on a VLANed interface, but you can create a VLAN on a bridged interface.

Is that where you wanted to go?

Cheers - Bob

Thanks Bob, fyi

VM (172.13.10.x) --> UTM625 (NAT 172.16.18.x) ---> UTM220 (172.16.51.x) ---> PHY Data Node (172.16.51.x)

From the same VM I need to get to several different PHY data nodes on different subnets 16.51.x, 16.14.x, 16.15.x, 16.13.x, 16.16.x etc.

The application uses DCOM which I can't route, therefore across these many UTMs I want to create a vlan so subnet 172.16.99.x is addressable from all.

Hope that kind of makes sense.

I'll take a look at what you've suggested.

Cheers.

I'd love to get away from DCOM, but it isn't my choice, the application vendor doesn't have anything else.  There is talk of OPC UA, but that is a separate can of worms with an unproven protocol. [:O]

Hi,

Have you tried this ?

How to configure RPC dynamic port allocation to work with firewalls

Limits the RPC dynamic port allocation so it can be addressed behind firewalls, the only thing that must not happen is NAT. If the service is NAT-ted then the system will not work.

I still think pseudo-wire/eompls/vpls over gre is the solution for you if you wish to span L2 architecture across multiple sites over WAN.

HTH.

P.