RED tunnel - software v.s. hardware

Question

Hi, 
 
 I tested Sophos XG Home and also XG trial (client and server both software VMs), but with both RED tunnel dont work. No L2, no VLANS, only L3. 
 I have also hardware XG86. When I use XG86 as server and XG Home (software) as client, all works - L2 and VLAN-s. 
 So, seems for RED I cant use software version, only hardware. Is this officially declared by Sophos? I dont see information about. I tested many days this to find out 
 But how when I put for RED server UTM? And client XG Home? Can UTM software server works with XG software client? 
 I cant use client as UTM.

LuCar Toni · Answer

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?

LuCar Toni · Answer

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.

RED tunnel - software v.s. hardware

Top Replies