Prevent rfc1918 traffic to escape wan interface

[Kakapa]

Hi everyone,
On the firewall feature, how can I do something like this:

pfSense® software Configuration Recipes — Preventing RFC 1918 Traffic from Exiting a WAN Interface | pfSense Documentation

docs.netgate.com

Btw, what's your opinions about these:
1. Is private ip targeted traffic exit to wan dangerous? And same to the reverse: is it necessary to prevent private ip sourced request to go from wan to lan?
2. If not on a wifi, but on mobile network, my app requests to ip address, it will also go out to wan. How to stop this?
Thank you

 

[ColinTaylor]

1. No.
2. I don't understand what you mean by "my app requests to ip address".

 

[sfx2000]

What is the use case here?

 

[Kakapa]

What is the use case here?

If a machine on the local LAN (e.g. 192.168.1.5) is configured to access private LAN addresses that are routed across a VPN tunnel (e.g. 192.168.100.0/24). If the VPN link were to go down, the router would no longer have an active route for 192.168.100.0/24, and a packet intended for 192.168.100.0/24 will be routed out the WAN interface using the default route. This could potentially provide information about the private LAN to someone with access to the ISP’s WAN network. A malicious user could even set up an imposter machine on the WAN network with a 192.168.100.0/24 address and pretend to be a machine on the inactive VPN link.

1. No.
2. I don't understand what you mean by "my app requests to ip address".

2. I'm sorry. I meant that if 1 was dangerous, then basically mobile internet network is more dangerous. As if my app used to connect to an internal server, and it continues sending request to that internal ip even after I switched from wifi to mobile network, that would cause some kind of leak to internet. Eg: if it's an authentication without encryption.

 

[sfx2000]

If a machine on the local LAN (e.g. 192.168.1.5) is configured to access private LAN addresses that are routed across a VPN tunnel (e.g. 192.168.100.0/24). If the VPN link were to go down, the router would no longer have an active route for 192.168.100.0/24, and a packet intended for 192.168.100.0/24 will be routed out the WAN interface using the default route.

Hmm... perhaps toss something like this into a shell script...

export INET_IFACE = ethX
iptables -A FORWARD -o $INET_IFACE -d 192.168.0.0/16 -j REJECT

 

[Kakapa]

Hmm... perhaps toss something like this into a shell script...

export INET_IFACE = ethX
iptables -A FORWARD -o $INET_IFACE -d 192.168.0.0/16 -j REJECT

thank you!
But considering your comments, I won't config it. Because you guys seem don't think this is a source of threat. I still don't have enough knowledge to deeply under this.
If it's just a minor, I won't make the config more complicated, because it's over my skills

 

[itpp20]

Hmm, a few weeks ago I had a client which could not get their printer to be found, it had a simple 192.168.1.22 address, a ping and traceroute showed it wanted to go via the WAN address (and then back in) which obviously doesn't work.
They did have traces of VPN connections left behind (software removed but adapter was still there), at the time I didn't think much of this behavior and used a 'route -p add' to reroute LAN traffic to their LAN gateway which solved the problem with the printer. (technically this route fix is the same as removing the left over adapter).

But this does beg the question: I would classify this as a serious issue resulting from a removed/deactivated VPN where 1918 traffic could flow beyond WAN.

 

[ColinTaylor]

What is the use case here?

If a machine on the local LAN (e.g. 192.168.1.5) is configured to access private LAN addresses that are routed across a VPN tunnel (e.g. 192.168.100.0/24). If the VPN link were to go down, the router would no longer have an active route for 192.168.100.0/24, and a packet intended for 192.168.100.0/24 will be routed out the WAN interface using the default route. This could potentially provide information about the private LAN to someone with access to the ISP’s WAN network. A malicious user could even set up an imposter machine on the WAN network with a 192.168.100.0/24 address and pretend to be a machine on the inactive VPN link.

That is just a cut and paste from the link in your initial post. I think the intent of the question was "what is your use case"? The sentence following your quote starts "While the chance of this being a problem is small...". You could always use the Network Services Filter to block traffic if it's an issue.

2. I'm sorry. I meant that if 1 was dangerous, then basically mobile internet network is more dangerous. As if my app used to connect to an internal server, and it continues sending request to that internal ip even after I switched from wifi to mobile network, that would cause some kind of leak to internet. Eg: if it's an authentication without encryption.

Private IPs won't be routed across a mobile internet connection.

 

[miniterror]

ISP's do not accept traffic from RFC1918.
So even if you somehow are able to sent RFC1918 traffic towards your ISP it just drops there

 

[itpp20]

ISP's do not accept traffic from RFC1918.
So even if you somehow are able to sent RFC1918 traffic towards your ISP it just drops there

Really?? for example if my ISP uses 10.10.10.* for managing modems and I use the same subnet locally and I can force WAN routing (via for example a faulty vpn, see my remark above) I could for example take over their DHCP server traffic as that subnet is marked as legit.

 

[itpp20]

Which reminds me some olden days where pptp(vpn) was using the same subnet on both ends, you either had to fiddle with routing or change your own subnet.

 

[Kakapa]

That is just a cut and paste from the link in your initial post. I think the intent of the question was "what is your use case"?


Private IPs won't be routed across on a mobile internet connection.

I coincidently tracerouted to my old subnet (which doesn't exist anymore), and saw that it break through the wan.
My ISP didn't drop it right away, though after 8 steps or so, finally it dropped.
It's a bit strange that on the route, among the public IPs, in the middle there were some private IPs 10.*.*.* which of course are not mine.
But that means the traffic to my old subnet actually broke to the internet.
That was a concern to me, as I changed my home network structure, and not sure that all my services have been changed accordingly. Those are still configured to connect to old subnet device IPs might leak to the internet.
I think maybe ISP in Vietnam doesn't drop the package right away?
I've just use the network service filter table to prevent the private IPs, and now the packages drop right at my gateway.

Thanks for the explain about the mobile network.
I'm not a network expert so my knowledge may be too low to talk to you guys...

 

[cptnoblivious]

Really?? for example if my ISP uses 10.10.10.* for managing modems and I use the same subnet locally and I can force WAN routing (via for example a faulty vpn, see my remark above) I could for example take over their DHCP server traffic as that subnet is marked as legit.

Some ISPs may NAT their internal networks. However, on the "internet" packets from the reserved networks isn't routeable.

IMO this is a pretty edge case and fairly low risk compared to the application layer risks. But it should be easy enough to block the 10.x block not used by your ISP (be careful here) and the 172.16 and 192.168 blocks outbound on your firewall.