Messages in this thread | | | Date | Wed, 5 Jul 2000 16:11:11 +0100 (BST) | From | Dale Amon <> | Subject | Redirected dns packets rejected |
| |
I'm having an argument with someone over the correctness of something they are doing on a linux firewall. They are capturing all DNS forwarding requests and redirecting them to a local cache only server that then responds to the original internal request.
Here is what the dump looks like from the requesting internal linux workstation:
15:33:29.084642 0:90:27:ce:52:98 0:0:b4:92:32:e8 0800 88: 10.0.0.10.1435 > 194.46.0.60.53: 5219+ (46) (ttl 64, id 50750)
15:33:29.085633 0:0:b4:92:32:e8 0:90:27:ce:52:98 0800 145: 10.127.13.1.53 > 10.0.0.10.1435: 5219 NXDomain q: home.netscape 0/1/0 (103) (ttl 64, id 2844)
15:33:29.085701 0:90:27:ce:52:98 0:0:b4:92:32:e8 0800 173: 10.0.0.10 > 10.127.13.1: icmp: 10.0.0.10 udp port 1435 unreachable [tos 0xc0] (ttl 255, id 50751)
As you can see, the dns request goes out from port 1435 to a real DNS server; but the reply comes back to that port from the cache serving on the firewall via it's internal REDIRECT. The linux workstation then seems to reject it.
I can see some sense in this, ie the return IP is not the same as the one on the request. This brings up two questions.
1) Is this indeed the way the tcp stack is supposed to operate? Is it intentional security, accidental security or a bug?
2) How do you convince some one they are doing the wrong thing? :-)
The workstation that the dump comes from is a 2.2.14 with international patches btw.
------------------------------------------------------ Use Linux: A computer Dale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste. Belfast, Northern Ireland ------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |