[SOLVED] Looking for advice for what to do when WAN is behind NAT with RFC1918 block required

[Grimson]

Just use basic firewall logic, first a rule to allow connections upstream and then block everything else.

https://www.netgate.com/docs/pfsense/book/firewall/index.html

[netblues]

Since you are not natting to the public internet, there is no point blocking rfc1918 ranges. Outbound your ip's will be natted to public (and they are rfc1918)
and inbound any packets originating from rfc1918 will end to the edge router doing nat which will drop them.
The idea with blocking them ahead of time is to lower the load caused by noise traffic arriving at the wan port.
So just refrain from blocking rfc1918 since pf is not directly connected to the internet.

[johnpoz]

@ulf-ulf-ulf said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

And can NAT into other networks.

Huh? You understand that pfsense would not be natting into corp or testing networks right.. Pfsense would only create an auto nat to networks that are wan (ie have a gateway on them)..

192.168.66 are their hosts on this network.. /24 is a large transit network.. You wouldn't really even want/need pfsense to nat into your transit network.. Your edge device would nat the downstream networks to public when needed to talk to the internet, etc.

[Ulf-Ulf-Ulf]

@netblues
Thanks for taking the time. I have trouble understanding what exactly you mean. So please allow me to quote you step by step and I will add my thoughts and/or confusion :)

@netblues said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

Since you are not natting to the public internet,

Got that!

there is no point blocking rfc1918 ranges.

Why not? As I understood it from the docs, RFC1918 blocking is primarily a security feature. You describe it as it is more of a performance feature.

Outbound your ip's will be natted to public (and they are rfc1918)
and inbound any packets originating from rfc1918 will end to the edge router doing nat which will drop them.

Could you elaborate on that? I don't understand what you mean.

The idea with blocking them ahead of time is to lower the load caused by noise traffic arriving at the wan port.

Same question as above. Performance feature? Security feature? Both? None really and something completely different?

So just refrain from blocking rfc1918 since pf is not directly connected to the internet.

And what should I do to prevent my test network to communicate with my corp network?

[johnpoz]

@ulf-ulf-ulf said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

And what should I do to prevent my test network to communicate with my corp network?

You put in a block rule on the top that says dest corp net block or reject.. It really is that simple..

Rules are evaluated top down as traffic enters interface from the network interface is attached too.. First rule to trigger wins, no other rules evaluated..

There is zero reason to block rfc1918 with the check mark..

[Ulf-Ulf-Ulf]

@johnpoz said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

@ulf-ulf-ulf said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

And can NAT into other networks.

Huh? You understand that pfsense would not be natting into corp or testing networks right.. Pfsense would only create an auto nat to networks that are wan (ie have a gateway on them)..

192.168.66 are their hosts on this network.. /24 is a large transit network.. You wouldn't really even want/need pfsense to nat into your transit network.. Your edge device would nat the downstream networks to public when needed to talk to the internet, etc.

hmm it seems like I have some false assumptions about how pfSense handles NAT. I guess I will have to dig into that a bit further.
Thanks so far. I'll came back later.

[johnpoz]

In your scenario - out of the box.. Pfsense would nat traffic from your local networks, lan, corp and testing to the pfsense wan IP.. Since your wan has a gateway.

But traffic between lan, corp and test would not be natted between them - unless you dicked with the automatic autobound nat rules.. Or you put gateways on these interfaces and pfsense thinks they are "wan" connections.

[netblues]

@ulf-ulf-ulf said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

@netblues
Thanks for taking the time. I have trouble understanding what exactly you mean. So please allow me to quote you step by step and I will add my thoughts and/or confusion :)

Got that!

there is no point blocking rfc1918 ranges.

Why not? As I understood it from the docs, RFC1918 blocking is primarily a security feature. You describe it as it is more of a performance feature.

Well, its both.
Picture this. Someone on the internet can spoof an rfc1918 ip and try to connect to your public ip.
Since upstreams don't filter this (and its a big issue) their packet will arrive.
Now if it is tcp it will be a syn packet to a port which your nat device may or may not accept and send
either an icmp reject, ignore it or reply to the syn with a syn ack
Obviously both the icmp and the syn reply won't travel much since target rfc1918 have no valid routes
and will be discarded upstream.
Now if a udp packet, or something with a strange protocol id and a specially crafted payload reaches your edge, exploiting an unknown bug, it may cause denial of service, or system compromise at worst.
(if pushing it to the extreme, the packet payload can cause injected code execution...)
so whoever want to send his trash and doesn't want an answer will use rfc1918 addresses as source, because she doesn' t want to be traced.
A dos attack is security or performance issue in the end.

Since no usable traffic will ever come from rfc1918 on the public internet, blocking it is just a safety measure. (but in reality won't protect you that much...)

Outbound your ip's will be natted to public (and they are rfc1918)
and inbound any packets originating from rfc1918 will end to the edge router doing nat which will drop them.

Could you elaborate on that? I don't understand what you mean.
Pfsense is not leaking private ip's to the internet, everything going out of your wan is promptly natted or denied.(unless of course you want it to happen.) So no need to block outbound rfc1918

So just refrain from blocking rfc1918 since pf is not directly connected to the internet.

And what should I do to prevent my test network to communicate with my corp network?

Plain ip rules as it has been already suggested.

[Ulf-Ulf-Ulf]

Thank you all!!! I will need some time to research all of your suggestions and wrap my head around it. But I do appreciate it very much!

[Ulf-Ulf-Ulf]

@netblues said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required:

Well, its both.
Picture this. Someone on the internet can spoof an rfc1918 ip and try to connect to your public ip.
Since upstreams don't filter this (and its a big issue) their packet will arrive.
Now if it is tcp it will be a syn packet to a port which your nat device may or may not accept and send
either an icmp reject, ignore it or reply to the syn with a syn ack
Obviously both the icmp and the syn reply won't travel much since target rfc1918 have no valid routes
and will be discarded upstream.
Now if a udp packet, or something with a strange protocol id and a specially crafted payload reaches your edge, exploiting an unknown bug, it may cause denial of service, or system compromise at worst.
(if pushing it to the extreme, the packet payload can cause injected code execution...)
so whoever want to send his trash and doesn't want an answer will use rfc1918 addresses as source, because she doesn' t want to be traced.
A dos attack is security or performance issue in the end.

Since no usable traffic will ever come from rfc1918 on the public internet, blocking it is just a safety measure. (but in reality won't protect you that much...)

Thanks! This part was really helpful. I would have never thought of that.

After quite some testing I think I have found what I was looking for in the first place. An easy rule to isolate my different networks from each other while at the same time give each of them unrestricted internet access.

So far I've come to the conclusion that an 'anything BUT' rule is the best fit for my needs.

If you have any other suggestions I'm eager to hear them.
But as my original question is solved I will mark this thread accordingly.

Thank you all! Have a nice day!