Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 1291 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

Sophos XG PCI Scan Failing - UDP500

Dave Hayes

Hello All. I hope everyone is having a good weekend.

So we are replacing about 62 older Sophos UTM 9.0's with Sophos XG's. All of these sites are have been connected for years with a hub and spoke VPN via site to site IPSec VPN tunnels and we have never had an issue passing PCI scans. However we have deployed 12 of the 62 XG's and each one of those fails with UDP port 500 open. We have looked at the solutions provided such as disabling strongswan or sending UDP500 to a blackhole (preferred). These get the XG's to pass the scan but UDP500 is needed for IPSec site to site tunnels and they fail. These devices have nothing enabled on the WAN ports under Device Access that would cause this.

Other than disputing it with the PCI Scan Vendor (Trustwave) how have you handled this situation.?

What is odd to me is that all the existing UTM's are working fine (They can initiate as well as respond to IPSec).  When I do a nmap scan against the IP address on UDP port 500 it shows as Open/Filtered on the UTM's but Open on the XG's which is likely why it is failing.

Others have suggested limited UDP500 via peer IP's and I can easily do that since all sites are static.  However, I do not think it is possible to limit this via a firewall rule.

Thanks everyone for any ideas.

Dave



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

    Hi ,

    Thank you for reaching out to Sophos Community.

    We tried to replicate the reported behavior in our lab environment.

    With a Blackhole configuration, we were unable to establish the IPsec tunnel.

    To allow IPsec communication we've created a new NAT rule(ID: 10) as below on top of the blackhole NAT rule(ID: 8). No firewall rule is required to allow/deny UDP 500 traffic.

    Note: Tunnel is configured with WAN interface Port2 as a listening interface in our lab environment.

    New NAT rule(to allow udp port 500 communication from specific IPs)

    Blackhole NAT ID: 8

    =============================================

    Translation settings:

    Original source: Static IPs of all branch locations
    Original destination: IPsec listening interface
    Original service: UDP port 500
    Translated source (SNAT): Original
    Translated destination (DNAT): IPsec listening interface IP address
    Translated service (PAT): Original

    Interface matching criteria:

    Inbound interface: IPsec listening interface
    Outbound interface: IPsec listening interface

    =============================================

    If the tunnel doesn't get establish after configuring a new NAT rule, please flush the connection for branch static IP from the console and try to reactivate the tunnel.

    ==> Login to SSH > 4. Device Console

    console> system diagnostics utilities connections v4 delete src_ip <Branch static IP>

    Example:

    console> system diagnostics utilities connections v4 delete src_ip 5.5.5.5

     

    We request you to share an observation of the PCI scan with this configuration.

  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to Sophos Community.

    We tried to replicate the reported behavior in our lab environment.

    With a Blackhole configuration, we were unable to establish the IPsec tunnel.

    To allow IPsec communication we've created a new NAT rule(ID: 10) as below on top of the blackhole NAT rule(ID: 8). No firewall rule is required to allow/deny UDP 500 traffic.

    Note: Tunnel is configured with WAN interface Port2 as a listening interface.

    New NAT rule(to allow udp port 500 communication from specific IPs)

    Blackhole NAT ID: 8

    =============================================

    Translation settings:

    Original source: Static IPs of all branch locations
    Original destination: IPsec listening interface
    Original service: UDP port 500
    Translated source (SNAT): Original
    Translated destination (DNAT): IPsec listening interface IP address
    Translated service (PAT): Original

    Interface matching criteria:

    Inbound interface: IPsec listening interface
    Outbound interface: IPsec listening interface

    =============================================

    If the tunnel doesn't get establish after configuring a new NAT rule, please flush the connection for branch static IP from the console.

    Login to SSH > 4. Device Console

    console> system diagnostics utilities connections v4 delete src_ip <Branch static IP>

    Example:

    console> system diagnostics utilities connections v4 delete src_ip 5.5.5.5

     

    We request you to share an observation of the PCI scan with this configuration.

  • 0 in reply to FormerMember

    Why all of this is necessary ? Snort have a built-in port-scanner detection sensor, even Sophos UTM have this functionality builtin.

    Telling the customers to create multiple NAT Rules on each firewall just because the firewall can't detect a port scan just shows the support team is trying to hide the actual problem instead of asking the Devs to fix them.

    Do you really want to force your customers to maintain multiple NAT Rules on every firewall that at any point shouldn't be necessary ?

  • 0 in reply to FormerMember

    Thank you for taking the time to send me this information and we will start this process and test.  However, this will really be a monumental process for 62 firewalls. And if they want to go from hub and spoke to Mesh then every firewall will need to have all these rules.  Also, it seems as though when we implement the "black hole" method the PCI compliance scanner complains about "Host Not Found".  We will test that further.

    Is there any reason why UDP port 500 is open instead of open!filtered?  I have tested nmap -sU -p500 <ip address> on several XG's in the field and many of them properly report back Open!filtered which would be correct.  But as soon as we enable IpSec site to site tunnels nmap reports back Open which is why the tests fail.  

    Even if I disable the IPSec VPN tunnels on an XG they still report open so it seems like if you enable IPSec at any time then it will permanently report open.  

    This really seems like quick a bit of hackery to get this to work as intended.

    Thanks for your reponse.