451–460 of 606 posts
Earlier quoted context omitted.
But it really doesn't. If you turned off NAT your computers would have the exact same security as they do with NAT.
Wrong. If I turn off the NAT on my router, my computers will not be able to get online. If I turn off the IPv6 firewall on my router, I won't see anything unusual. And yes, this has happened to me when I forgot to compile the IPv6 conntrack module.
Earlier quoted context omitted.
When you say no ipv4 on regular phone plan, you mean no routable ipv4 on the internet, or no ipv4 at all?
Regular phone plans on my carrier have a private IPv4 address behind CGNAT.
Earlier quoted context omitted.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist. > In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't…
It is not, you guys are talking from a specific american ISP perspective where you have these modem+router+gateway+firewall combo devices. Not everyone gets that. Many get just a modem and buy a cheap router which may not have a firewall. MANY more get just a modem and their laptops are directly exposed to the internet (!!!), those you can't do much about, but many put a "router" that's just a cheap wifi access point…
What cheap router are you buying that doesn't have a firewall. I think the problem is when people hear "firewall" they think the router is running pfSense or something. Even cheap routers will have a basic, non-configurable, firewall that will block inbound connections. That is separate from NAT and has nothing to do with IPv4/IPv6.
Earlier quoted context omitted.
The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior and explicitly uses the term "NAT filtering". When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advant…
NAT: iptables -A POSTROUTING -o wan0 -j MASQUERADE Firewall: iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m state --state INVALID -j DROP iptables -A FORWARD -i lan0 -j ACCEPT iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This…
Earlier quoted context omitted.
Datapoint of 1: With Cox as my ISP, I can get a /64 just by configuring my DHCPv6 client to request it, but if I wanted a /56 or /48 I would have to contact someone at my ISP.
I'm beginning to think it might be a US thing. Every time there's an ISP horror story, it's always the US.
Earlier quoted context omitted.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything. NAT doesn't protect you from either of these.
So, if you have NAT but a grossly misconfigured router, it might not be secure? Quick question - do you think that "security by obscurity is not security"? And, as a follow-up, when you park your car do you ensure your laptop bag is out of sight, maybe locked away in the boot? Because here's a mindblowing concept that'll change the way you see the world - you can have a door lock but it won't make you secure. You nee…
Before you engage in discussions, may I suggest to look into RFC 4787, especially section 5 about filtering behaviors of NAT: https://datatracker.ietf.org/doc/html/rfc4787#section-5 Several things can be correct at the same time: * NAT is not a firewall * NAT can still filter traffic (and practically always does) * NAT can hence still provide security features * The real world often does not care about original defin…
I think you're on my side in this discussion, but I have to say you can't really point at an RFC and say it settles an argument; RFCs can also be wrong about stuff, and the further you get from bits laid out on the wire, the less trustworthy they are.
This is pretty much the opposite of what I'm doing. I'm saying: look at that RFC, where they write that NAT filters incoming traffic! If even people writing RFCs say this, it is obviously an established notion of the term "NAT".
What I'm arguing against is this obsession with being technically correct; that NAT can only be literally "network address translation" and nothing else, and that you are incompetent if you think otherwise (plenty of examples for this further down).
What I'm saying is: look, things in the real world are messy, and terms can change their meaning.
Earlier quoted context omitted.
It doesn't though. NAT edits your outbound connections to appear to come from the router's IP; it doesn't do anything to make inbound connections harder.
If you don't initiate a corresponding outbound connection first then any attempt at an inbound connection will be dropped (unless you have a DMZ configured ofc). The router literally can't forward the traffic because it doesn't know where it should go.
IP packets have a "destination IP" field in the header. The router knows where to forward packets because it reads that IP out of the header.
Right, IPv6 is annoying because it lacks NAT. There's a big difference between something being a huge pain to deal with (IPv6) and being insecure.
IPv6 doesn't "lack" NAT. There is nothing preventing you from using ULA addresses inside your network (IPv6's version of RFC-1918) and then running NAT for those addresses on your router. IPv6 just doesn't _need_ NAT, but it is still an option.