Using a RED Site to Site Tunnel will cause problems, if you use a static route with gateway routes. 

Did you generate any kind of routes or is your entire routing based on the VLANs, which are extended by the bridge? 

In general, the RED protocol works the same on hardware and software. But you created a bridge, correct? 

Please learn what is layer 2. RED is pure L2 tunnel. There is no needed any routing, any IP. Only you need bridge RED interface to physical interface and allow traffic by firewall.  The result is just like you have put very long RJ45 cat cable between devices. It can be managed in switches level, without any IP or routing. You can use VLANs. VLANs also go through tunnel, only you need make VLAN interface both in tunnel and physical nic side and then bridge them, as without it sophos device accepts only untaged traffic..

I cannot help you anymore further, if you do not provide the proof of tcpdumps and conntracks (maybe droppacketcaptures). Otherwise we cannot comment on this situation anymore. 

I ask once more - have you tested it? Do VLAN-s work?

Hello Ivar,

this is a voluntary community help forum here. That said, I ask why you are so rude to LuCar Toni?

He is just asking for some info to help you out. But you try to teach him things, he really knows already. (Have a look at his forum-points 53413, this should tell you something...)

Maybe you are open to discuss your problem:

Ethernet Bridging - VLANs

Ethernet bridges enable hosts to communicate through layer 2 by connecting all of the physical and logical interfaces in the system into a single layer 2 domain. The bridge is a logical interface with a MAC address and an MTU (maximum transmission unit). The bridge MTU is the minimum MTU among all its members. By default, the bridge’s MAC address is the MAC address of the first port in the bridge-ports list.

This is how a linux kernel doas bridging.

Example:

https://tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO-4.html#ss4.4

Of course is a MAC-address assigned to your bridge, this is normally the same address as your first w port.

If using SW-type of firewall installer, this could be by chance the SAME MAC for both ends of the RED tunnel.

This could cause problems and that's what Lucar Toni wanted to verify with your help.

HTH.

MAC address is offtopic. This is not interest me. The fact is - softwared RED dont work and hardware RED works. Have you tested this? Have you put VLANs work in software RED? Me dont interest Sophos internal programming - me interest what works and what dont. I dont have time for philosophy. And me interest how to püut things to work if at all possible. Me interest do you have tested it. Me interest what is Sophos official answer for this feature.

I won't work on this, if you insist on your rude manner, sorry.

You had been given a chance to get this going.

Because hardware network license cost 50 eur /year. But software XG Home is totally free. Also software hyper-V virtual version is much faster than hardware box. I must make decision - buy license or not. Why I must al all experiment, test and search in forums? Normal company says cleraly - this function work and this function is not allowed and I dont have more questions. Why I must predict how Sophos works? And  "there is maybe some problems" is not answer. Things in enterprise class firewalls work or they dont work. Chinese cheap stuff maybe work or maybe not. Sophos is not cheap.

Why you then waste my time if you dont use Sophos RED products?

I waste your tme?!?

Don‘t be impertinent!

Yes, you just waste my time, nothing more.

But yes, Sophos XG bridge is not "pure bridge", but it makes arp relay. You cant see MAC addresses from other side of bridge, only see bridge MAC. But this dont make sense in RED aspect of view. RED is still pure L2  and passthrough VLANs. RED is also some kind of bridge. It can only work or not work, there is no half-working state. But there exists also lots of bridges without MAC addresses and without arp relays. Example Sophios UTM, Mikrotik, Pfsense, CheckPoint, Palo Alto etc. They just transfer all packets to other side, withou MAC interaction with arp relay. But Sophos XG bridge can also do more than example Palo Alto. It can route L2 packets to L3 interface (when source have no acknowledge about L3 interface at all). Ist like "by force" packets translation. Mikrotik bridge is also very powerful - it can make NAT for MAC addresses. Every products bridge is unique and different from other products. Bridges can be implemented very different ways. But this have nothing to do with RED.   

But yes, Sophos XG bridge is not "pure bridge", but it makes arp relay. You cant see MAC addresses from other side of bridge, only see bridge MAC. But this dont make sense in RED aspect of view. RED is still pure L2  and passthrough VLANs. RED is also some kind of bridge. It can only work or not work, there is no half-working state. But there exists also lots of bridges without MAC addresses and without arp relays. Example Sophios UTM, Mikrotik, Pfsense, CheckPoint, Palo Alto etc. They just transfer all packets to other side, withou MAC interaction with arp relay. But Sophos XG bridge can also do more than example Palo Alto. It can route L2 packets to L3 interface (when source have no acknowledge about L3 interface at all). Ist like "by force" packets translation. Mikrotik bridge is also very powerful - it can make NAT for MAC addresses. Every products bridge is unique and different from other products. Bridges can be implemented very different ways. But this have nothing to do with RED.   

I will agree with the other's you are being a bit rude for a community forum, but I will try to give you an answer. I don't completely understand your issue, but I will try to help.

RED is a proprietary layer 2 protocol to mimic a point to point layer 2 connection. It is not identical to plugging a cable in between devices, but's it's damn good at what it does for traversing layer 3 devices. It does require MAC addresses though, using ARP proxy or broadcast.

RED can pass MAC's over the tunnel. I have plenty of tunnels setup that do. Small sites have a vlan that is a bridge of another vlan on the main Sophos device. They operate as if they are on the same network. This is all based on using RED devices, like RED50.

RED S2S is a little different. It doesn't matter if you are using a software appliance or hardware. SFOS does not like bridging networks that exists on 2 different SFOS appliances in my experience. I always just create a /30 for the P2P interface and route the traffic between firewalls. It's cleaner in the end. You are not sending broadcast and multicast traffic over the tunnel, using up your bandwidth. This works with hardware appliances or software.

Sophos has sales engineers that will help you evaluate this setup. They can get high level engineers involved if needed. If your plan is to try to run XG home in production, I would advise against it. It's against the license terms and isn't supported. You can run the trial version of XG for fully supported configs.

Mike

Its not against license terms. I get license from Sophos, for XG Home. But have you tested RED tunnel? Between software server (running on Vmware, Hyper-V or plain PC) and software client?  Do VLAN-s works?

It is against the terms if you use XG home in a production environment, regardless if you officially downloaded it from Sophos. Sophos provides trail license for proof of concept setups and provides resellers with NFR licenses to test with. XG home licenses were never meant for users to try out production setups. They are meant for home users to run XG in their home network to learn the product. I'm not the license police, so I don't care, just wanted to inform you.

Yes, I run multiple software appliances and hardware. Software appliances are primarily on Hyper-V, but some are on VMWare. There is no difference between them. Software appliances may run a little faster if you have fast host processors vs the equivalent appliance.

VLAN's work fine for all, but I use a /30 P2P address for the RED interface and add the VLAN's to that interface after the tunnel is up. I do not use layer2 on site to site tunnels. I either use static routing or OSPF pointing to the RED interface IP on both sides. I only use layer2 when using a RED device.

Typically, if you have a SFOS appliance on both side (software or hardware) it is better to route the traffic. Again, you "can" bridge the vlans so both sites operate as the same network, but I highly recommend you don't do this. The Linux OS underneath can get confused by the routes being injected and any diagnostics in the future are hindered.

Any reason you can't use layer 3 routing over the layer 2 RED tunnel? What is your end goal? Knowing the full setup may help to see if RED is even the right option.

But I am home user. I dont have any company here. I am pensioner. My firewall is in my kichen. Do you want picture? I can make picture from my home and firewall........ VLANs are L2. If you dont use L2, then there are no any VLANs. VLANs dont need IP addresses and routing. So, seems you havent at all tested layer 2 RED with VLANs, without IPs, between 2 software XG. Can you please test this and post result. ........No, its not better to route traffic. Routed traffic cant connect devices directly, only through gateway. Example I have devices with gateways to some other firewall or router, then they cant communicate,  because traffic goes to wrong gateway. I must make then static route to every device, but this goes to abnormal configuration. But my main reason why I need L2 RED, is other. I have in city TV service provider digibox. It works only in fixed location and dont allow any routing. Now I put L2 RED tunnel between city home and my countryside and watch TV there without problems. I already tested this. L2 RED works only when server side is hardware XG (I have one). Many years ago I tested this also with Sophos UTM. And UTM allows to use software server side. But today UTM dont present anymore free RED for home users.

You are mixing up so many things.

First of all. The Software (OS) is the same. There is literally no difference in the OS between a hyper-v managed installation and a installation on a Sophos owned component. 

But there could be an issue on other parts of your installations. First of all, you should check your registration (and with that your license). If you license is not in the state "sub scripted", modules will not work as intended. If you deffer to register the Appliance, it will not work. 

RED is completely based on certificates. In another thread you point out, you have NTP out (For no reason?). Without a correct time sync, the Tunnel could be broken.

And again: It does not matter, what kind of appliance installation you use. If the hyper-V installation is corrupt (has issues) it will not work. That has no implication on the installation you use. 

You could go down the road and use a Sophos UTM home: https://www.sophos.com/en-us/free-tools/sophos-xg-firewall-home-edition It is also available. 

What license you talk about? Sophos XG Home license is sent by email right after download . What is "correct time"?  And I ask again - have you at all tested software RED server with software RED client?  Do your VLANs worked? 

Just to complete the view. 
This is perfectly working with a Azure and hyper-V configuration.

Only obstacle was to configure the VLAN management in both setups. Both this is actually not an Sophos issue, instead configuration issue. See: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/configure-virtual-local-areal-networks-for-hyper-v  && https://docs.microsoft.com/de-de/azure/vmware-cloudsimple/cloudsimple-vlans-subnets

Of course this is not applicable for a hardware appliance, as the interface is simply the entry point and not the entire vSwitch // VPCs. 

So for example: 

SFV6C8_AZ01_SFOS 19.0.0 GA-Build317# tcpdump -ni any host 192.168.134.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
23:08:12.760640 reds3, IN: ethertype ARP, ARP, Request who-has 192.168.134.1 tell 192.168.134.2, length 28
23:08:12.760665 PortA, OUT: ethertype ARP, ARP, Request who-has 192.168.134.1 tell 192.168.134.2, length 28
23:08:12.760640 TestBridge, IN: ethertype ARP, ARP, Request who-has 192.168.134.1 tell 192.168.134.2, length 28
23:08:12.760640 TestBridge.100, IN: ARP, Request who-has 192.168.134.1 tell 192.168.134.2, length 28
23:08:12.760692 TestBridge.100, OUT: ARP, Reply 192.168.134.1 is-at 00:0d:3a:22:81:b5, length 28
23:08:12.760694 TestBridge, OUT: ethertype ARP, ARP, Reply 192.168.134.1 is-at 00:0d:3a:22:81:b5, length 28
23:08:12.778102 reds3, IN: ethertype IPv4, IP 192.168.134.2 > 192.168.134.1: ICMP echo request, id 2102, seq 0, length 64
23:08:12.778102 TestBridge, IN: ethertype IPv4, IP 192.168.134.2 > 192.168.134.1: ICMP echo request, id 2102, seq 0, length 64
23:08:13.769823 reds3, IN: ethertype IPv4, IP 192.168.134.2 > 192.168.134.1: ICMP echo request, id 2102, seq 1, length 64
23:08:13.769823 TestBridge, IN: ethertype IPv4, IP 192.168.134.2 > 192.168.134.1: ICMP echo request, id 2102, seq 1, length 64
23:08:13.769823 TestBridge.100, IN: IP 192.168.134.2 > 192.168.134.1: ICMP echo request, id 2102, seq 1, length 64
23:08:13.769870 TestBridge.100, OUT: IP 192.168.134.1 > 192.168.134.2: ICMP echo reply, id 2102, seq 1, length 64
23:08:13.769871 TestBridge, OUT: ethertype IPv4, IP 192.168.134.1 > 192.168.134.2: ICMP echo reply, id 2102, seq 1, length 64
23:08:17.798873 TestBridge.100, OUT: ARP, Request who-has 192.168.134.2 tell 192.168.134.1, length 28
23:08:17.798877 TestBridge, OUT: ethertype ARP, ARP, Request who-has 192.168.134.2 tell 192.168.134.1, length 28
23:08:17.817553 reds3, IN: ethertype ARP, ARP, Reply 192.168.134.2 is-at 00:15:5d:26:b0:0e, length 28
23:08:17.817553 TestBridge, IN: ethertype ARP, ARP, Reply 192.168.134.2 is-at 00:15:5d:26:b0:0e, length 28
23:08:17.817553 TestBridge.100, IN: ARP, Reply 192.168.134.2 is-at 00:15:5d:26:b0:0e, length 28

You see, The Bridge with VLAN100 is perfectly fine in responding. 

And at this point, it has nothing to do with the installation. The OS of the Firewall is working. The VLAN Packets are flowing with a tagged packet through the data plane. 

Here simply a tcp app: 

23:16:05.769962 reds3, IN: ethertype IPv4, IP 192.168.134.2.38210 > 192.168.134.1.4444: Flags [S], seq 2384252568, win 29200, options [mss 1300,nop,nop,sackOK,nop,wscale 7], length 0
23:16:05.769962 TestBridge, IN: ethertype IPv4, IP 192.168.134.2.38210 > 192.168.134.1.65003: Flags [S], seq 2384252568, win 29200, options [mss 1300,nop,nop,sackOK,nop,wscale 7], length 0
23:16:05.769962 TestBridge.100, IN: IP 192.168.134.2.38210 > 192.168.134.1.65003: Flags [S], seq 2384252568, win 29200, options [mss 1300,nop,nop,sackOK,nop,wscale 7], length 0
23:16:05.770092 TestBridge.100, OUT: IP 192.168.134.1.4444 > 192.168.134.2.38210: Flags [S.], seq 3092099697, ack 2384252569, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:16:05.770096 TestBridge, OUT: ethertype IPv4, IP 192.168.134.1.4444 > 192.168.134.2.38210: Flags [S.], seq 3092099697, ack 2384252569, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
23:16:05.787299 reds3, IN: ethertype IPv4, IP 192.168.134.2.38210 > 192.168.134.1.4444: Flags [.], ack 1, win 229, length 0
23:16:05.787299 TestBridge, IN: ethertype IPv4, IP 192.168.134.2.38210 > 192.168.134.1.65003: Flags [.], ack 3092099698, win 229, length 0
23:16:05.787299 TestBridge.100, IN: IP 192.168.134.2.38210 > 192.168.134.1.65003: Flags [.], ack 1, win 229, length 0

At this point, i will stop responding to you as a user, as i find it rather rude. Those DMs you send me will be forwarded to a moderator as well.