Firewall blocking incoming connections
Author
I'm wondering how firewalls block incoming connections. I don't mean software firewalls on client computers, I mean firewalls on a network like a corporate firewall. Does the filtering generally occur at the IP level or at the TCP level, or is it different with every firewall?
I would expect that most would examine the packet coming in or going out. If it is heading to or from a location that is blocked, it does not send the packet. Simple as that.
Author
I'm referring to firewalls that block incoming connections, like most corporate firewalls. I would assume that this could be done by blocking the initial SYN packets being sent from outside the network. This would only allow TCP data to go through the network though. If it was done at the IP layer, it seems the firewall would have to "remember" what connections have been established from inside the network so that it can let the right packets through from outside the network.
There is no need to remember which connections have been made from the inside to the outside in a normal firewall situation (ie everyone in the internal network has its own internet ip address). however i am guessing that you are talking about a firewall that is a NAT as well.
On a NAT it is impossible for an incoming connection (ie TCP SYN packet) to find its way to the correct computer since multiple pcs are sharing a single ip internet ip address. So by default those packets get discarded anyway. however if you set up the NAT to map a particular public port to an internal ip address and port you can redirect packets to that pc. The firewall does not need to know what connections pc have on hand since any SYN packet arriving on a particular port will be mapped to only one internal ip address (assuming a simple NAT, and ignoring the possibility of clustering).
The firewall has to keep track of port mappings so it can send the right packets to the right internal address. for each ip address it would have to keep track of which port the internal pc is expecting data, as well as what ip/port combo the external pc will be communicating on. UDP get even more complicated since it is a stateless protocal. TCP at least ahs the luxary of having a handshake so the NAT knows when a connection starts, as well as a timeout/disconnect which allows a mapping to be removed when the connection is no longer valid.
FYI, you can easily create software firewalls and NATs that block connections based on rules as well as share a single ip address based on rules. in fact most hardware NATs at the consumer level use an embedded copy of linux. You really should take a look at linux and iptables (which may have been superceded since i have not used linux firewalls in a while). Just get two (or more) network cards in the pc you want to use as your firewall/NAT. The firewall pc will use one network card for the external network (ie plug it into your cable modem or other external network), and the other nic cards will be for pcs (or switchs which can have pcs plugged into them). you can do this with windows as well, but i am not sure you can find software that is as customizable as the linux software for free.
Long story short, incoming TCP connections are NOT blocked or dropped because of some rule. They are responed to saying teh port is closed because the firewall/nat does not have a service on that port thus it is not open. You can expect the firewall/nat to be able to guess which of the internal pcs the incoming connection is meant for. in other words, the packet has an undefined destination thus it is considered bound for the firewall/nat itself.
TCP packets are filtered at the TCP level if there is a rule to filter them at that level unless another rule filters them higher up the chain that is at the IP level. So the short short answer. It depends on the rules the sys admin makes assuming the connection has a valid destination meaning the port on the firewall/nat is actually mapped to an internal ip/port combo for TCP packets.
On a NAT it is impossible for an incoming connection (ie TCP SYN packet) to find its way to the correct computer since multiple pcs are sharing a single ip internet ip address. So by default those packets get discarded anyway. however if you set up the NAT to map a particular public port to an internal ip address and port you can redirect packets to that pc. The firewall does not need to know what connections pc have on hand since any SYN packet arriving on a particular port will be mapped to only one internal ip address (assuming a simple NAT, and ignoring the possibility of clustering).
The firewall has to keep track of port mappings so it can send the right packets to the right internal address. for each ip address it would have to keep track of which port the internal pc is expecting data, as well as what ip/port combo the external pc will be communicating on. UDP get even more complicated since it is a stateless protocal. TCP at least ahs the luxary of having a handshake so the NAT knows when a connection starts, as well as a timeout/disconnect which allows a mapping to be removed when the connection is no longer valid.
FYI, you can easily create software firewalls and NATs that block connections based on rules as well as share a single ip address based on rules. in fact most hardware NATs at the consumer level use an embedded copy of linux. You really should take a look at linux and iptables (which may have been superceded since i have not used linux firewalls in a while). Just get two (or more) network cards in the pc you want to use as your firewall/NAT. The firewall pc will use one network card for the external network (ie plug it into your cable modem or other external network), and the other nic cards will be for pcs (or switchs which can have pcs plugged into them). you can do this with windows as well, but i am not sure you can find software that is as customizable as the linux software for free.
Long story short, incoming TCP connections are NOT blocked or dropped because of some rule. They are responed to saying teh port is closed because the firewall/nat does not have a service on that port thus it is not open. You can expect the firewall/nat to be able to guess which of the internal pcs the incoming connection is meant for. in other words, the packet has an undefined destination thus it is considered bound for the firewall/nat itself.
TCP packets are filtered at the TCP level if there is a rule to filter them at that level unless another rule filters them higher up the chain that is at the IP level. So the short short answer. It depends on the rules the sys admin makes assuming the connection has a valid destination meaning the port on the firewall/nat is actually mapped to an internal ip/port combo for TCP packets.
I think the filtering would happen at the TCP/UDP level, since A) its usually the routers responsibility to go from the IP to TCP layer (I might be confusing this with the Ethernet to IP translation) and B) the IP header does not contain any source port or destination port information, however it does contain a source address and destination address.
Firewalls need to know to know which port a packet is destined for to do any type of port filtering and it would only know this if it were dealing with information from a TCP/UDP header.
This is just my take on things, I'm prolly talking out my ass again =) So take this with a grain of salt. I'm sure somebody will correct me if I'm wrong.
-=[ Megahertz ]=-
Firewalls need to know to know which port a packet is destined for to do any type of port filtering and it would only know this if it were dealing with information from a TCP/UDP header.
This is just my take on things, I'm prolly talking out my ass again =) So take this with a grain of salt. I'm sure somebody will correct me if I'm wrong.
-=[ Megahertz ]=-
Author
I'm referring to firewalls that prevent incoming connections, not a NAT that acts like a firewall. The specific network I have in mind has static IPs (public IPs, not address translated private IPs), but has a firewall at the gateway to the public internet. The firewall does no port filtering at all, it simply blocks incoming connections.
For example, any computer behind the firewall can access any webpage over a port 80 TCP connection. However if that computer runs a web server, no computer on the outside of the firewall will be able to access it, since the firewall blocks incoming connections.
So the two ways I can imagine that this works are at the IP layer or at the TCP layer. If the filtering is done at the TCP level, the firewall can simply block the initial SYN packet coming from outside the network, so the connection is never initiated. If the filtering is done at the IP layer, since IP is stateless, the firewall would have to remember what packets were sent "recently" from a node inside the network to a node outside the network, so it knows to let packets in. But it seems that it would still have to process TCP or UDP headers to know what ports are being used.
It seems to me that it would be difficult, if not impossible, to block incoming connections at the IP layer... is this the case?
For example, any computer behind the firewall can access any webpage over a port 80 TCP connection. However if that computer runs a web server, no computer on the outside of the firewall will be able to access it, since the firewall blocks incoming connections.
So the two ways I can imagine that this works are at the IP layer or at the TCP layer. If the filtering is done at the TCP level, the firewall can simply block the initial SYN packet coming from outside the network, so the connection is never initiated. If the filtering is done at the IP layer, since IP is stateless, the firewall would have to remember what packets were sent "recently" from a node inside the network to a node outside the network, so it knows to let packets in. But it seems that it would still have to process TCP or UDP headers to know what ports are being used.
It seems to me that it would be difficult, if not impossible, to block incoming connections at the IP layer... is this the case?
A firewall that blocks incoming connections would do one of at least two things:
1) It could be state-less, and just block SYN packets, at the TCP level. It may block UDP or ICMP, or let it through.
2) It coulde be state-ful, and remember what servers/ports have been sent to from within the corporation, and only allow packets back if they are return packets within some time-out. This is like a NAT, without the actual address translation.
1) It could be state-less, and just block SYN packets, at the TCP level. It may block UDP or ICMP, or let it through.
2) It coulde be state-ful, and remember what servers/ports have been sent to from within the corporation, and only allow packets back if they are return packets within some time-out. This is like a NAT, without the actual address translation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
