Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 26 subscribers
  • Views 782 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

INVALID_TRAFFIC

richie913

Hi,

I am having some major issues working out why some of my packets are being classed as INVALID_TRAFFIC on my Sophos XG210.


A bit about my set up...


I have an XG210 acting as a perimeter firewall, and is also the gateway for my DMZ zone. I have an XG450 that is acting as my LAN firewall. DMZ interfaces on both firewall pairs are connected to a stack of DMZ switches. The Aruba stack also have a tagged port passing DMZ traffic via our Core to our TORs and our VMWare environment.


The LAN firewall also has a LAN interface configured to our LAN Core switch.


Static routing on my Core switch routes all traffic through to the XG450s.


Rules are configured on the XG450s allowing specific IPs/Services from the LAN through to the DMZ. Static routing is set up passing the traffic to the XG210s out of the DMZ interface (via the Aruba stack)


Rules are configured on the XG210 allowing LAN IP ranges to the DMZ IP ranges.


I have two VMs, one configured with a LAN IP and the other with a DMZ IP.


From the DMZ VM, I can ping the gateway (DMZ Firewall, and also the LAN firewall, and every server in the LAN – temporarily by design whilst I troubleshoot this issue). I see packet captures hit correct rules, and everything seems fine.


However, from the LAN VM I cannot ping the DMZ VM. I can ping the DMZ gateway but when running a packet capture, it seems that I am not seeing any ICMP echo requests, but only replies – which are then classed by the DMZ firewall as INVALID_TRAFFIC.


I put wireshark on the LAN VM and it seemed the ICMP response was hitting my core and then not getting a reply. However, the LAN firewall packet capture sees the incoming packet and shows it as allowed and passed to the DMZ firewall. The DMZ firewall only shows the echo reply.


I have no idea why this is happening, and why it is happening only one way. Can someone please put me out of my misery!

Some packet captures to hopefully help…

Packet Capture on the LAN firewall – showing the LAN source pinging (ICMP type8 – request) the DMZ destination. So the ping is hitting the LAN firewall…


Packet Capture on the DMZ firewall – not seeing the LAN source address, but instead seeing the DMZ source address and the ICMP header at type 0 (reply)



Successful pings from the DMZ server (via the DMZ interface) pinging the LAN VM and the DMZ VM

So the routing on the DMZ side are fine...the packet goes the way its meant to and hits all of the correct rules. It just seems that the LAN-DMZ routing/filters/rules is wrong or misconfigured somewhere - but I just can't see where?!

For testing purposes I have made the rules fairly open - LAN->DMZ and DMZ-LAN are open for any ranges and any services, but this INVALID_TRAFFIC tells me it is something before it even gets to the rule filtering.

Any help or suggestions would be greatly appreciated, and if there is any more info I can give to help people help me then just let me know!

Thanks in advance to anyone who can help!



This thread was automatically locked due to age.
Parents
  • 0

    Hello Richie,

    Thank you for contacting the Sophos Community! 

    Can you create a LAN to LAN rule in both XGs. To rule out an issue with the Firewall rules, since you are using a bridge you might need to have this.

    As per the Ping probably there is a static route in one of the Core switches that is sending the Ping another way?

    Regards,

Reply
  • 0

    Hello Richie,

    Thank you for contacting the Sophos Community! 

    Can you create a LAN to LAN rule in both XGs. To rule out an issue with the Firewall rules, since you are using a bridge you might need to have this.

    As per the Ping probably there is a static route in one of the Core switches that is sending the Ping another way?

    Regards,

Children
  • 0 in reply to emmosophos

    Hi,

    Thanks for your reply!

    I tried adding in a LAN to LAN rule but it has made no difference.

    I am not sure if it helps but the DMZ firewall only has a WAN and DMZ interface configured. The LAN FW has a LAN and DMZ interface, which is where I made sure that on that firewall there were rules to allow LAN->DMZ and DMZ->LAN for all services temporarily. Could my issue be that the inbound and outbound packet is via the same interface?

    With regards to the LAN VM and the core switch route the core sends the packet to the LAN FW, the LAN FW sends the packet to the DMZ. The LAN VM can successfully ping the DMZ firewall IP address. See packet capture below from both firewalls:

    LAN FW packet capture:

    I see the echo request come in from LAN to DMZ firewall IP via Port9 (LAN interface) and out via port 3 (DMZ Interface). The echo reply then comes from Port3 from the DMZ firewall and out port 9 back to the VM.

    DMZ FW packet capture:

    I see the request hit the DMZ firewall via the LAG_DMZ (DMZ Interface) then the reply goes back out the same interface to the LAN address. I presume it is hitting rule 0 as it is now taking the Device Access rules over any filter rules?

    When pinging from the LAN VM to the DMZ VM, I see the same packets on the LAN FW, but then get the issue on the DMZ FW where I'm only seeing the ICMP replies, but being marked as invalid as I presume the requests are getting lost somewhere?

    As I am writing this I am starting to wonder whether it is asymmetrical routing happening somewhere - but I am struggling to see where...

    Apart from what is available to me in the GUI, is there any extended or more verbose logging I can enable to run tcpdumps? Or anything else I should focus on?

    Thanks again

  • 0 in reply to richie913

    Hello Richie,

    You would need to see via the advanced shell (5>3)

    # tcpdump -eni PortX 

    Try SSHing in 3 different windows to the XG so you can run the command on each involved interface. 

    Also you can use the console for the drop packet, this should tell you which interface the packet is coming and being dropped 

    console > drop-packet-capture 'host x.x.x.x' 

    Regards,