Stop RFC1918 addresses from going to WAN (PCI DSS requirement)

Hi,

your request looks very much like you have a configuration error in your firewall rules?

Please provide more details about the issue?

Ian

Most likely, somewhere the MASQ tick is missing LAN to WAN? 

Ah, I believe I did not clearly explain my issue. I am using Sophos XG with SFOS 17.5, where the XG is our Internet gateway.  We use private IP addresses on our internal LAN as is commonly done. 

When we send traffic out to the Internet our source IP address is correctly NATted to the outside/WAN IP address of the firewall. So I don't believe masquerading is the issue.

However, if a user sends traffic from my LAN destined to a *private* IP address, the Sophos sends it out to my ISP.  The packet would have a source IP address of the firewalls WAN IP, and the destination private IP address the user requested.  Instead, I want to drop these outgoing packets since they should not be going out anyway. 

It becomes a bigger issue for us as our ISP actually routes the traffic, and they use private IP address on their own networks.  For example, if I execute a vulnerability scan of private IP address space from my local LAN, I actually reach and get responses from some servers that belong to my ISP.  And then I need to explain this to our auditors and convince them these are not our devices...

I was reviewing PCI DSS requirements and the more I think about it I don't think this is a PCI issue for me.  PCI says we cannot leak our private IP address space out to the Internet.  But in this case we are not doing that. It is our ISPs private IP address space that is leaking into my network.

I don't know if I am allowed to include HTTP links here but we are not the first to encounter this issue with this ISP, as I can see discussions about this problem on Reddit for example.

https://www.reddit.com/r/networking/comments/2gvr0j/private_ip_addresses_resolving_beyond_our/

I hope that better explains my issue.  ...brian

Sounds again like a config issue. This should not happen! 

Can you perform a tcpdump of this behavior?

https://community.sophos.com/products/community-chat/f/knowledge-base-article-suggestions/105811/how-to-tcpdump-on-xg

If you can spot a pattern of this traffic, you can start to debug this with conntrack. 

Conntrack on XG will list the firewall rule and outbound interface. 

So basically you should be able to find the incorrect firewall rule / reason for this. 

So i would start to "find the root cause" instead of simply blocking those packets.  

Hi,

You can do it on the Sophos XG firewall same as the Cisco router or firewall. You can create a new Firewall User rule on the top (source LAN and Destination WAN) with an action of Drop. And Destination Subnet/Device must be only IP Subnets as defined in the RFC1918. It will drop the packets and will not move on the WAN. 

 10.0.0.0        -   10.255.255.255  (10/8 prefix)
 172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
 192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Thanks, Deepa and LuCar.  I will pursue these with my firewall folks and we'll see if these can help us resolve this.  ...Brian

I'm seeing the same thing in one of our firewalls. It's an XG230 running 17.5MR8. While I agree that it is best to find the route cause. Isn't this also a routing error in the firewall? Shouldn't any WAN traffic to a private IP be automatically dropped?

Not if someone has setup a device on the network that is advertising that address. Please use the firewall diagnostics and tracers to the address.

ian

Added stuff, remember there are a lot of home router users with no understanding of networking.

Make sure NAT is enabled otherwise you public ip, after a while, will be blacklisted.

It happened during a POC with another vendor where the guy did not configured NAT properly and we were blacklisted. This occurred more than 10 years ago.

Hi Brian Cole 

This is standard routing that happens on all network devices.  If the XG does not have a route for that network that is being requested, it will send it out its default gateway.

Only way to stop this is by creating a drop rule as already advised.

Thanks!

Thanks, Deepak and KingChris.  I ended up adding rules as you indicated, and now we no longer send out traffic to private IP addresses.  Much appreciated.  ...brian

Thanks, Deepak and KingChris.  I ended up adding rules as you indicated, and now we no longer send out traffic to private IP addresses.  Much appreciated.  ...brian