I vibe'd a basic ticketing system in just under an hour that does what we need. So not 20 mins, but more like 45-60.

I used to be connected to the community where stuff like this was passed around. But that was a long, long time ago.

More info here.

https://www.agweb.com/news/policy/politics/usaid-dismantling...

In Linux, even with nftables you still have the concepts of "chains" which goes all the way back to the ipchains days. IME this isn't a particularly helpful way of viewing things. With PF you can simply make your policy decisions on in or out and on which interface(s). Also I'm not sure I ever saw a useful application of why you'd apply a policy on the pre/post-routing chains that wasn't achievable elsewhere in PF and in a simpler way.

Also I've never been a fan of having a command that just inserted or deleted a policy instead of working from a configuration file. (nft "config" files are really just scripts that run the command successively.) I get why some folks would want that (it probably makes programmatic work a lot easier) but for me it was never a benefit.

Anyhow it's been a long time since I've had to do this kind of thing so maybe I'm out of touch on the details. Happy to hear about how I'm wrong lol.

Actually it doesn't. Well, not really.

With NAT you're generally talking about either 1:1 or 1:many (Masquerading).

In all cases the device doing the NAT maintains a table which is referenced for every matching packet that arrives or leaves.

In 1:1 NAT, the IP in the packet header (Layer-3) is simply rewritten from one address to the other whenever a packet matching both addresses in the NAT table leaves or arrives.

In 1:many NAT, the source port is randomized because you can run into collisions when multiple clients are connecting to the same server:port. So in that case the NAT table contains IP addresses as well as ports. When a return packet arrives, it checks the NAT table and rewrites both the L3 and L4 (port) info before passing it along.

Often times firewalls will randomize the source port when doing 1:1 NAT as a security measure, but after all these years I don't really remember why that's helpful. :-\

But that's really the extent of tracking connections with NAT.

Now when you're talking about firewalling, there's a lot more to track, such as connection start/stop/timeouts/lifetimes, total throughput, TCP state (handshakes, sequence numbers, etc.), closing open sessions when seeing things like TCP RSTs or FINs or ICMP unreachables. The amount of data and CPU is dramatically higher, and tailored to the software doing the firewalling. I believe in many cases simple L3/L4 rewrites can happen in hardware.

I haven't talked about any of this in several years so I hope I'm making sense.

Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only.

Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest.

For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range.

As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space.

Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent.

https://community.cisco.com/legacyfs/online/legacy/0/8/0/600... https://www.cisco.com/c/en/us/support/docs/ip/network-addres...

Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.

Are you implying your ISP itself is going to do this? Because the Internet at-large doesn't have routes for your internal address space.