Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Say that you and I both have IPv6 - to make things easier, otherwise IPv4 with real IPv4 addresses will do fine. You want to connect your box to mine directly, that is without going through some intermediate server that forwards traffic. We both have the usual "Count Dracula + virgin" stateful firewalls in our routers and no software "firewalls" in our own boxen. How do we do it? That is, if we want to write a protocol to break through the firewall and effectively declare to the router that access is authorised. (And knowledge of or fiddling with the router settings is not allowed btw. Nor any hacking allowed.)

[XGS_Is_On]

Send one another UDP flows with the same source and destination port, or source and destination reversed. Your outbound port 10,000 to port 10,000 connection will open a flow in the firewall in that direction, mine will open a flow in mine. Your source 10000, destination 20000 will open a flow your side, my source 20000 destination 10000 will open the path for you.

[Weaver]

Excellent.  

Here we go. Some speculative vague+ignorant stuff.

I’m wondering how firewalls’ behaviour might or might not vary. [btw - I have omitted IPv4/v6 protocol version field from what follows.]

It seems to me to be possibly a very daft idea, but I’m wondering if
        a match on:                          (src_addr, dst_addr, IP_protocol_x=prot1 )
        might actually be handled as: (src_addr, dst_addr, IP_protocol_x=*) under certain circumstances. And this is intentionally left vague.

Or     a match on:             (src_addr, dst_addr, IP_protocol_x=prot1, dest_port=port1)
        might be treated as: (src_addr, dst_addr, IP_protocol_x=prot1 or *, dest_port=*)

This kind of wider-related matching, if it exists, is either really useful, or really dangerous and in any case should be an option that is highly configurable.

I don’t know about the variability in firewalls’ behaviours / capabilities / options, as you see. Usual level of ignorance from me.

It might be handy here, to be able to use a busting technique set up with UDP to also affect other protocols even. So saying "I trust machine x completely" would mean "all incoming traffic from x is ok". But it might be better to have the option of filtering this and being more selective about the allowed traffic types from machine x.

It would be so great if there were an RFC for firewall config protocol, and also for remote firewall config, where requests are of course either signed, or else encrypted and contain a field that is a pre-shared key. Much better than hole-busting trickery.

[XGS_Is_On]

Unlikely on both counts. A full layer 3 match of source, destination and IP protocol would be expected: anything else is a bug. Where there's a transport protocol in use a full L4 source/destination match would be expected.

No room for any wildcards. The inbound flow has a counterpart outbound flow, so TCP doesn't work, or it doesn't.

I'm talking about (mis)using statefulness in basic firewalls here. Obviously the rulesets can be anything from a full 5tuple match to any-any.

[johnson]

This write up of firewall and NAT traversal from tailscale is a good read and seems relevant:
https://tailscale.com/blog/how-nat-traversal-works/

[XGS_Is_On]

It would be so great if there were an RFC for firewall config protocol, and also for remote firewall config, where requests are of course either signed, or else encrypted and contain a field that is a pre-shared key. Much better than hole-busting trickery.

This is interesting if I understand where you're going.

May an entity control their firewalls remotely en masse: absolutely. Template pushes are a thing.

Remote firewall configuration by a third party no ifs, no buts, just no.

The business departments / enterprises talk and agree modifications to their firewall sets to allow them to achieve objectives.

Third parties and firewalls just no. If they're third party contractors give them a VPN onto the network.

At no point should a firewall respond to a configuration request from outside the perimeter of trust it requires in. People connecting to the intranet via VPN are within that trusted group.

As are orchestration services and management services with the necessary permissions, access and authentication. Let them have that if they need access

An RFC to allow remote management of firewalls is not happening as they're proprietary kit with proprietary management platforms. Want to give a third party permission to change firewall policies give them a VPN to your orchestration service, let them modify templates, etc as necessary.

[craigski]

@weaver If I understand your original question correctly, I think what you are describing in effect is the same 'hole punching'  that is already widely used for applications such as VoIP, Games, etc albeit this does require a server to help with establishing the session.

[Weaver]

@johnson absolutely amazing work from tailscale and a very good write-up. They really have worked hard at this.

It just reminds me once again what a scandal IPv4 NATs are. I’m so glad that I saw the light and got rid of NAT 15 years ago. When I was a Demon and Zen user, I didn’t have NAT myself with either ISP at the end, even before I moved to AA.

[XGS_Is_On]

If it doesn't require unsolicited inbound connectivity, and most things don't, NAT is fine.

[Alex Atkin UK]

@johnson absolutely amazing work from tailscale and a very good write-up. They really have worked hard at this.

It just reminds me once again what a scandal IPv4 NATs are. I’m so glad that I saw the light and got rid of NAT 15 years ago. When I was a Demon and Zen user, I didn’t have NAT myself with either ISP at the end, even before I moved to AA.

But what do you actually use that doesn't work with NAT?  I mean for most things double-NAT is not even an issue, good thing thanks to CG-NAT now.

[Weaver]

I don’t really know how to answer that. I’ve been NAT-free for so long. I did get utterly sick of having to remotely log into a server belonging to a customer and then reconfigure port NAT redirection of RDP so that I could then go and look at another machine.

That’s not what I really object to most, it’s the cost to developers and the loss of so many opportunities over the years for a rich spread of imaginative peer-to-peer apps, probably including a number of ideas that we have not yet thought up because of IPv4 NAT. Mind you, to be fair, using IPv6 gets us out of the peer-to-peer problem. Again, the existence of NAT has prolonged the existence of IPv4 when it should have died well over ten years ago because of address exhaustion. I do have to say that the very existence of firewalls is also a crucial factor in stalling the growth of peer-to-peer novel apps. Imagine a world without firewalls! What things would we then be able to do? Or at least a world without overly restrictive firewalls with unhelpful default rules that prohibit useful communications as well as nuisance and DDOS behaviour. We need protection against the latter to be also placed deeper within the network, and we need defences that are far more reactive, context-sensitive, controllable and relevant. A final admission, my visceral loathing of IPv4 NAT and clinging on to IPv4 simply because of inertia is far from logical; I’d say that there’s definitely something irrational about my attitudes here. I do hate old designs that should IMHO have been put to bed a long time ago. It’s like my dislike of TCP, also not entirely logical, but that’s another rant for another day, most definitely.

Hypocrisy alert: I confess that a few years ago I found a use for IPv4 NAT within my Firebrick router. I discovered that it’s a way of letting me talk to the admin i/fs of my four modems which are attached to the router. The Firebrick NAT-rewrites the packets exchanged between a modem i/f and my own machine on my main LAN.

[XGS_Is_On]

I don’t really know how to answer that.

I can entirely empathise: I haven't a clue how to answer yours but will try

The RDP issue: shouldn't be using RDP across the Interwebs but if you were why not destination NAT on outside for port 3389 mapping 3389 to one machine, 3390 to 3389 on another, 3391, etc, or better yet 33389 for first one to make port scanning more dull for nosey folks?

Peer to peer apps: are you familiar with Napster, KaZaA, eDonkey, etc? We've moved towards centralising compute, storage, etc, for efficiency but for other things we certainly have peer to peer - play games online and in many cases they're peer to peer or one of the players hosts. Been knocking around since the dialup days. With dynamic IP addresses have to have lobbies anyway, these can easily be used to punch holes in NAT.

Firewalls are required for the same reason most of us have to lock our doors at night. The default deny at the end of them is essential. Sad as it is they are necessary. Without them we'd all be at the mercy of bad actors. The default deny at the end means my big router's ruleset is this, and 2 of them direct the system to hardware offload and fasttrack, not allow/deny, one is cosmetic:

[admin@MikroTik] /ip/firewall/filter> print
Flags: X - disabled, I - invalid; D - dynamic
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough
 1    chain=forward action=fasttrack-connection hw-offload=yes in-interface-list=LANs log=no log-prefix=""
 2    chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related in-interface=SFP3-YouFibre1 log=no log-prefix=""
 3    chain=forward action=accept in-interface-list=LANs log=no log-prefix=""
 4    chain=forward action=accept connection-state=established,related in-interface=SFP3-YouFibre1 log=no log-prefix=""
 5    chain=input action=accept in-interface-list=LANs log=no log-prefix=""
 6    chain=input action=accept protocol=icmp in-interface=SFP3-YouFibre1 log=no log-prefix=""
 7    chain=input action=accept connection-state=established,related,untracked in-interface=SFP3-YouFibre1 log=no log-prefix=""
 8    chain=input action=accept in-interface=ether13-RTR-Mgmt log=no log-prefix=""

[admin@MikroTik] /ip/firewall/nat> print
Flags: X - disabled, I - invalid; D - dynamic
 0    chain=srcnat action=masquerade out-interface=SFP3-YouFibre1 log=no log-prefix=""

DDoS protection of a good standard is reactive, context-sensitive, controllable and relevant. I'll find you a picture of the controls I have on my lab here, though this is enterprise grade, not whatever is found in regular home equipment which is, frankly, worthless. DDoS protection at home is a nice placebo but doesn't actually do anything.

Don't think it should be deep in the network: it should be as close as possible to the Internet-facing edge so that you don't waste capacity transporting junk into your core. Ideally the junk doesn't touch the network at all: systems that detect DDoS based on telemetry and then have the network stop advertising those prefixes and have a specific screening service take over are pretty cool.

[Alex Atkin UK]

Don't think it should be deep in the network: it should be as close as possible to the Internet-facing edge so that you don't waste capacity transporting junk into your core. Ideally the junk doesn't touch the network at all: systems that detect DDoS based on telemetry and then have the network stop advertising those prefixes and have a specific screening service take over are pretty cool.

That's one of the big things about Cloudflare proxy isn't it, they can redirect attacks to their dedicate DDoS black hole.  Although its sad that the only solution is to have tons of spare bandwidth to syphon off the invalid traffic.

[Weaver]

I would very much like to know about ISP-side firewalls. Keeping evil traffic away further upstream rather than having it come down your internet access link only to get dropped by your firewall. I wish A&A offered this as for me it would be a killer feature to have.

Has there been an ISP that offered such a thing ever? Some highly dubious ancient recollection says "PlusNet" ?

That kind-of links into my thinking earlier about firewall remote control, but with some major differences; before I was thinking about more dynamic firewall control driven by code whereas here I’m thinking that ISP-side firewalls would have a configuration that was set up in a control panel, and hopefully also accompanied by a very very lightweight machine-to-machine API protocol.

[Chrysalis]

I agree with XGS on NAT.

As an example Weaver I was only recently thinking about this, I had the NAT rules on my firewall set to log traffic (from when I enabled for diagnosing a problem) and was seeing some end points accessing those ports, so is this a NAT problem?  Well the reality is if I was using routable IPs to each client device the ports would still be open on the firewall.

I even deliberately run some virtual servers on NAT now in datacentres to save IP addresses as they have become really expensive, there is no technical issues, some hobby projects I run which give no revenue, I saved the rental expenditure on dedicated IP addresses.  One of my servers, I pay more for the IP's than leasing the bandwidth and hardware.

I also used to run a big project some years back across over 40 physical servers, only 2 out the 40 had internet facing IP's rest was all NAT, the backend etc.

Many datacentres do indeed offer firewalls of their own in the control panel they supply as well.

I remember back in the pre Windows XP SP2 days, a friend of mine installed Windows XP on his ICS machine back in the day (before NAT routers were widespread), was directly connected to ISP modem, within seconds of it booting up it was compromised by a internet virus, XP firewall in those days wasnt default deny inbound.