how-to block ads
|
|
Share Topic
 |
 |
|
|
|
 Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3
 ·Shaw
| reply to Komputerguy
Re: UDP Port scans and you First a rule of thumb that should help here. Unsolicited inbound traffic is always directed at the IP address that your ISP assigned you, UNLESS it is for a forwarded, or triggered port, or you have a machine in the DMZ.
NAT stands for Network Address Translation, which means your Linky keeps a table as to where inbound traffic should be directed. If the inbound traffic is in response to an outbound connection (ie a table entry exists), then the traffic is directed back to the internal machine that made the connection. For example you see the outbound log message for your system to connect to DSLReports, and all the traffic the DSLReports sends back (using your ISP assigned IP address) is then translated by the linky to the IP address of the system your surfing DSLReports with. Since this connection is already made you do not get a log event for this. This also applies in the case of port forwarding. When inbound traffic arrives for some port, by having port forwarding setup, you are instructing your linky to translate all traffic arriving on this port to the IP you entered to forward to (since there is no connection, one is made and it appears in your logs as traffic going to the forwarded machine). The DMZ is just a bigger extension of this, where all unconnected traffic is translated to go the system you placed in the DMZ. So lets say you placed machine x.x.x.x in the DMZ and your ISP assigned IP address is y.y.y.y. Looking at the traffic immediately before your linky, the packets say, send to y.y.y.y and then in your linky, it looks at the packet and sees that its unconnected inbound traffic and translates y.y.y.y into x.x.x.x and passes it through to the DMZ system (and its logged as a connection to the system in the DMZ). If you don’t have DMZ enabled, then the packets just before your linky still say send to y.y.y.y but in your linky, if the traffic is unconnected inbound traffic, it doesn’t know where to forward the packets to and punts/blocks them (and logs it as a connection to your ISP IP address which really is the external IP address of your linky).
So again if the logged traffic (meaning as it appears in your logs) is addressed to your ISP assigned address, then it was blocked at the linky. If logged traffic is addressed to an internal IP, then it was either forwarded, Triggered, or sent there because DMZ was enabled. This is why Forwarding and DMZ (and to a much much lesser degree Triggering) can be dangerous as it in effect bypasses the security of a NAT. Also remember that SPI and DMZ are mutually exclusive in the current firmware versions and SPI rules. Meaning if SPI is enabled, it disables DMZ. Bill_MI had mentioned a reason why he thought there were some problems with Linkys hanging using the dummy IP address in the DMZ, and I’m betting he right on the money (the table is only so big and connection last x amount of time by default, so if you send lots of connections (for each IP, and for each Port a separate connection is created in the NAT table, then you over flow the table and crash the linky). I would think a hard reset should restore the Linky, unless the over flow trashes some code in memory (possible).
So RoadRunner is not filtering every port, the addresses are just being translated as per your configuration instructions. Are you seeing UDP traffic (a log entry) for all the ports Sygate scans? If so then they don’t filter any ports. The most UDP ports I’ve ever seen an ISP filter is three and those were the NetBIOS ports of 137, 138, and 139. Sometimes I think my local ISP is somewhat unique in filtering UDP port 31337.
Whew, this is more then I wanted to write here, but its still somewhat of a simplified view of what the linky does, but I hope it helps you understand what the the NAT does and how a couple of different features (forwarding, DMZ, logging, etc) work in your linky and how they would impact scans. As you can imagine setting up a dummy IP address in the DMZ tell the linky to forward all unconnected traffic to the bit bucket as there isn't a real machine there to return anything.
Maybe I should have put this in a new topic called NAT and you.
Blake | | |
|
| said by Link Logger:
The DMZ is just a bigger extension of this, where all unconnected traffic is translated to go the system you placed in the DMZ. So lets say you placed machine x.x.x.x in the DMZ and your ISP assigned IP address is y.y.y.y. Looking at the traffic immediately before your linky, the packets say, send to y.y.y.y and then in your linky, it looks at the packet and sees that its unconnected inbound traffic and translates y.y.y.y into x.x.x.x and passes it through to the DMZ system (and its logged as a connection to the system in the DMZ). If you don’t have DMZ enabled, then the packets just before your linky still say send to y.y.y.y but in your linky, if the traffic is unconnected inbound traffic, it doesn’t know where to forward the packets to and punts/blocks them (and logs it as a connection to your ISP IP address which really is the external IP address of your linky).
I understand everything you said (I think) and it makes sense. What confuses me is the one strange behavior I see with the Sygate UDP scan. When I have neither SPI or DMZ on, it says I have "unprotected ports" (meaning not stealthed, I presume) and then proceeds to scan but never seems to finish. I see absolutely no activity in the Linksys log.
said by Link Logger:
Bill_MI had mentioned a reason why he thought there were some problems with Linkys hanging using the dummy IP address in the DMZ, and I’m betting he right on the money (the table is only so big and connection last x amount of time by default, so if you send lots of connections (for each IP, and for each Port a separate connection is created in the NAT table, then you over flow the table and crash the linky). I would think a hard reset should restore the Linky, unless the over flow trashes some code in memory (possible).
I've been using the DMZ trick for months now and never remember experiencing a lock-up. Interesting.
--
What can possibly go wrong? | |
|
