Access to some webservers through firewall
Hello! I have configured my firewall with iptables to basically let in only answers on my requests, which works fine at about 95% of all webservers. But when I'm trying to access some sites my firewall blocks the answers like this: Nov 26 10:04:18 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.35 DST=222.82.183.145 LEN=1490 TOS=0x00 PREC=0x00 TTL=54 ID=8559 DF PROTO=TCP SPT=80 DPT=1789 WINDOW=15972 RES=0x00 ACK URGP=0 which is correct, because I was trying to contact www.bahn.de (213.83.12.10). I think that they have a load balancer who sent me to that ip-address, but as my firewall did not open a connection there it blocks the packages. Any ideas what I can do about that? By the way, I had the same problem with suse-firewall, too. Best regards, Ralf Ronneburger
On Monday, 26. November 2001 10:31, you wrote:
Nov 26 10:04:18 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.35 DST=222.82.183.145 LEN=1490 TOS=0x00 PREC=0x00 TTL=54 ID=8559 DF PROTO=TCP SPT=80 DPT=1789 WINDOW=15972 RES=0x00 ACK URGP=0
I _think_ these are keep-alives from the webserver that are being dropped because the stateful exception has timed out and been deleted from the connection table.
Ralf Ronneburger
Bjoern
Bjoern Engels wrote:
On Monday, 26. November 2001 10:31, you wrote:
Nov 26 10:04:18 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.35 DST=222.82.183.145 LEN=1490 TOS=0x00 PREC=0x00 TTL=54 ID=8559 DF PROTO=TCP SPT=80 DPT=1789 WINDOW=15972 RES=0x00 ACK URGP=0
I _think_ these are keep-alives from the webserver that are being dropped because the stateful exception has timed out and been deleted from the connection table.
Are these timeouts adjustable? Ralf
On Monday 26 November 2001 10:31, Ralf Ronneburger wrote:
Hello!
I have configured my firewall with iptables to basically let in only answers on my requests, which works fine at about 95% of all webservers. But when I'm trying to access some sites my firewall blocks the answers like this:
Nov 26 10:04:18 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.35 DST=222.82.183.145 LEN=1490 TOS=0x00 PREC=0x00 TTL=54 ID=8559 DF PROTO=TCP SPT=80 DPT=1789 WINDOW=15972 RES=0x00 ACK URGP=0
which is correct, because I was trying to contact www.bahn.de (213.83.12.10). I think that they have a load balancer who sent me to that ip-address, but as my firewall did not open a connection there it blocks the packages.
Any ideas what I can do about that? By the way, I had the same problem with suse-firewall, too.
Best regards,
Ralf Ronneburger
Sorry for the late reply, maybe your problem is solved already. I suppose you're running pppoe (DSL) ? There is a problem with pppoe with certain servers. Maybe this is what you are experiencing, maybe something else: With tcpdump you see the initial handshake between the client and the server, the client request, but never the data sent by the server. When this is so in your case, you could try the following: 1. compile your kernel to have netfilter tcpmss support. 2 insert a rule "iptables -A FORWARD -j TCPMSS \ -p tcp --tcp-flags SYN,RST SYN --clamp-mss-to-pmtu" 3. set mtu=1492 and mru=1492 in /etc/pppd/options 4. restart pppd and firewall If your problem is solved, I would like to know. Andreas Baetz ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been scanned for the presence of computer viruses. **********************************************************************
Hello Andreas, first of all thanks to your reply! And yes, I do have DSL and so I've done a tcpdump on my external interface and below is, what happend: Andreas Baetz wrote:
On Monday 26 November 2001 10:31, Ralf Ronneburger wrote:
Hello!
I have configured my firewall with iptables to basically let in only answers on my requests, which works fine at about 95% of all webservers. But when I'm trying to access some sites my firewall blocks the answers like this:
Nov 26 10:04:18 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.35 DST=222.82.183.145 LEN=1490 TOS=0x00 PREC=0x00 TTL=54 ID=8559 DF PROTO=TCP SPT=80 DPT=1789 WINDOW=15972 RES=0x00 ACK URGP=0
which is correct, because I was trying to contact www.bahn.de (213.83.12.10). I think that they have a load balancer who sent me to that ip-address, but as my firewall did not open a connection there it blocks the packages.
Any ideas what I can do about that? By the way, I had the same problem with suse-firewall, too.
Best regards,
Ralf Ronneburger
Sorry for the late reply, maybe your problem is solved already. I suppose you're running pppoe (DSL) ? There is a problem with pppoe with certain servers. Maybe this is what you are experiencing, maybe something else: With tcpdump you see the initial handshake between the client and the server, the client request, but never the data sent by the server.
Actually there is some reply from the server, the whole conversation
between the two of them is this:
10:09:40.228711 217.82.186.42.2764 > 213.83.12.10.http: S
120893175:120893175(0) win 5808
When this is so in your case, you could try the following: 1. compile your kernel to have netfilter tcpmss support. 2 insert a rule "iptables -A FORWARD -j TCPMSS \ -p tcp --tcp-flags SYN,RST SYN --clamp-mss-to-pmtu" 3. set mtu=1492 and mru=1492 in /etc/pppd/options 4. restart pppd and firewall
If your problem is solved, I would like to know.
Andreas Baetz
********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been scanned for the presence of computer viruses. **********************************************************************
On Wednesday 05 December 2001 11:32, Ralf Ronneburger wrote:
Hello Andreas, Actually there is some reply from the server, the whole conversation between the two of them is this:
10:09:40.228711 217.82.186.42.2764 > 213.83.12.10.http: S 120893175:120893175(0) win 5808
(DF) 10:09:40.271757 213.83.12.10.http > 217.82.186.42.2764: S 3703832914:3703832914(0) ack 120893176 win 31944 (DF) 10:09:40.271973 217.82.186.42.2764 > 213.83.12.10.http: . ack 1 win 5808 (DF) 10:09:40.272986 217.82.186.42.2764 > 213.83.12.10.http: P 1:533(532) ack 1 win 5808 (DF) 10:09:40.343660 213.83.12.10.http > 217.82.186.42.2764: . ack 533 win 31944 (DF) The packets go out with an mss of 1452, that is your pmtu should be 1492 (mss+20+20) Is your mtu (and mru) set to 1492 ? (I would suppose it is set to a smaller value)
Now does it still make sense to try, what you've told me to do? First I would check if your mtu (mru) are set to 1492. Your mss seems to be set as if this was your mtu.
And what is the desease I'm curing with that? As far as I understand it: Your running pppoe. That means your ip packets (ppp0) are wrapped in pppoe packets, which are sent through your eth interface. This adds 8 bytes. Your eth Interface has an mtu of 1500, so your pppd should have an mtu of 1492. The server has to be told to send only packets with max 1492 bytes so they can be wrapped in pppoe (by the isp router). This is done with the "-j TCPMSS --clamp-mss-to-pmtu" rule. It discovers your pmtu and sets mss accordingly. If the server sends larger packets, they don't reach your eth Interface. The server is told by the mss value how big the max packet size should be. Now this seems to work. But if your mtu of your ppp0 Interface is smaller than 1492, <speculation> your isp router knows about this from the ppp negotiation and doesn't send you those packets. Now it could tell the server that it should fragment the packet, which doesn't work in some cases etc. </speculation>
But I could be totally wrong and would appreciate any correction. Andreas Baetz ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been scanned for the presence of computer viruses. **********************************************************************
participants (3)
-
Andreas Baetz
-
Bjoern Engels
-
Ralf Ronneburger