Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 25 replies
  • Answers 2 answers
  • Subscribers 43 subscribers
  • Views 4308 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

RED tunnel - software v.s. hardware

Ivar Pikker1

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.



Added TAGs
[edited by: emmosophos at 10:40 PM (GMT -7) on 3 Jun 2022]
[locked by: FloSupport at 10:56 PM (GMT -7) on 6 Jun 2022]
  • 0 in reply to MichaelBolton

    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.

  • 0 in reply to Ivar Pikker1

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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? 

  • 0 in reply to LuCar Toni

    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. 

    __________________________________________________________________________________________________________________

  • 0

    Hello,

    This user has been moderated.

    Sophos encourages the sharing of constructive advice and criticism and the community forums are therefore as open and free from content control as possible; however any type of personal attack towards members of the community won't be tolerated. 

    • Personal attacks on other visitors, Sophos employees and/or affiliates or moderators.

    https://community.sophos.com/w/getting-started/91/sophos-community-terms-and-conditions-of-use

    Regards,

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
Unfiltered HTML