Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 22 replies
  • Subscribers 29 subscribers
  • Views 2061 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

Issue with VLAN between 2 XG firewalls with V19 home edition

matthieu

Hello,

I encounter weird communication issues on a network shared between two XG firewalls since V19 upgrade. A drawing being better than a long speech, here's my network topology :

In short : 

192.168.1.x is the LAN side of my ISP router.

192.168.2.x is my internal LAN, protected by XG1. Since some of my hosts cannot be directly plugged to XG1, I put a second XG (XG2) in another room, with some other hosts connected to it. XG1 and XG2 are interconnected with a trunk comprised of VLAN 100 for my LAN (and some other VLANS). VLAN 100 is member of LAN bridges on both XG1 and XG2. Actually, XG2 is simply used as a simple manageable L2 switch, extending XG1's LAN. 

The issue : 

This configuration used to work in V18.5. But since V19 migration, communications between LAN hosts on XG1 and XG2 are blocked, with a weird behavior

- the desktop on the left can flawlessly reach the Internet

- the desktop fails to communicate with the server on the right. A wireshark trace shows that a few first packets are exchanged, then communications are blocked.

- when pinging from desktop to server, the first packet gets a successful answer, but all following packets don't get answers. Same behavior with a ping from server to desktop.

- the desktop cannot connect to the XG1 admin interface on its LAN IP (even if admin is allowed on zone LAN) 

Since it looks like communications are blocked not immediately but after a few successful messages, I was thinking about firewall erroneously dropping packets. Unfortunately both the firewall log and the drop-packet-capture command are silent. IPS logs are silent too.

Any idea would be helpful.

Best Regards,

Matthieu



This thread was automatically locked due to age.
  • 0

    Hello,

    Here's some more troubleshooting information. It seems that this issue belongs to the class of strange issues. When I ping from desktop to server, only the first ping request gets an answer as explained in my previous post. But as soon as I start "tcpdump icmp" on XG1 console, the issue disappears instantly and ping works flawlessly as long as tcpdump runs. If I stop the tcpdump command, the ping problem comes back instantly. If I restart tcpdump pings works again, etc ....

    Looks like a bug somewhere ?

    Thanks in advance for any help

    Best Regards

    Matthieu

  • 0
    matthieu said:
    This configuration used to work in V18.5. But since V19 migration, communications between LAN hosts on XG1 and XG2 are blocked, with a weird behavior

    Please Go to System-->Admininstration --->Backup and Firmware -->Firmware and share the status of the firmware shown on GUI

    Are you taking regular backup of Sophos XG firewall ? and checked the issue by rollback with worked firmware version V18.5?

    Regards

    "Sophos Partner: Infrassist Technologies Pvt Ltd".

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to Bharat J

    Hello,

    Here's the firmware info of XG1 (XG2 is identical)

    I do have daily backups of XG1, but not XG2 (well, home usage :-)). I didn't do a rollback test yet but I noticed the issue just after upgrading to V19. To do a rollback test, if I upload v18.5 on both firewalls will it keep the configuration ? 

    Best Regards

    Matthieu

  • 0 in reply to matthieu

    If no major or minor changes done to Sophos XG and after upgrading the firmware caused the issue, it would be great if you raise the case with Sophos Support Team to investigate the root cause.

    Thanks and Regards

    "Sophos Partner: Infrassist Technologies Pvt Ltd".

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to matthieu

    Hi matthieu, 

    I see in your screenshot below you are already running v19.0 MR1 build #365. 

    I assume this is still an issue on MR1? Does the issue also disappear on MR1 when you run tcpdump? I ask because we did fix an issue in MR1 related to how VLAN packets pass through the system, so I wanted to confirm if your issue is still present on v19.0 MR1. 

  • 0 in reply to bobbylam

    Hello,

    Actually yes, the issue is still present with MR1 on both firewalls (they were already in MR1 when I did the tcpdump test mentioned in my previous post). I encountered the issue with V19 GA then upgraded to MR1 hoping that MR1 would solve the issue, but it didn't.

    Best Regards

    Matthieu

  • 0

    Where did you do the packet capture? One the firewalls? Webadmin or CLI? 

    Maybe there is a routing issue? Try doing the packet capture on Webadmin and check for the routes, if the packet arrive but no outbound packet, check the drop packet capture on the affected firewall. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hello,

    I did the packet capture on XG1 directly through the Unix shell. Given the various tests I made I don't think it is a L3 issue but rather a L2 issue (desktop can access the Internet flawlessly for instance). drop packet capture doesn't provide any information on concerned trafic. 

    Best Regards

    Matthieu

  • 0 in reply to matthieu

    So it is likely a problem with the routing. If drop packet capture does not indicate a dropping, it could be a routing part. Check conntrack: conntrack -E |grep ClientIP

    Then ping on the client. See if you see the connection opening or not. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    HEllo,

    I will do the contrack test when I'm back home. Maybe I'm wrong, but I really doubt it is a routing issue. I can't figure out how it could be a routing issue since the client and the server are on the same network, the first ping request gets an answer (and it is the same with http requests : the dialog starts flawlessly then is blocked after a few exchanges), and this configuration used to work with 18.5. I think it is probably a level 2 issue, and bobbylan's reply seems to be a good candidate.

    Best Regards

    Matthieu

Unfiltered HTML