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:
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
On Monday 26 November 2001 10:31, Ralf Ronneburger wrote:
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:
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 <mss 1452,sackOK,timestamp 73022819 0,nop,wscale 0> (DF) 10:09:40.271757 213.83.12.10.http > 217.82.186.42.2764: S 3703832914:3703832914(0) ack 120893176 win 31944 <mss 1452,sackOK,timestamp 110780581 73022819,nop,wscale 0> (DF) 10:09:40.271973 217.82.186.42.2764 > 213.83.12.10.http: . ack 1 win 5808 <nop,nop,timestamp 73022824 110780581> (DF) 10:09:40.272986 217.82.186.42.2764 > 213.83.12.10.http: P 1:533(532) ack 1 win 5808 <nop,nop,timestamp 73022824 110780581> (DF) 10:09:40.343660 213.83.12.10.http > 217.82.186.42.2764: . ack 533 win 31944 <nop,nop,timestamp 110780589 73022824> (DF) But after the last reply of the server nothing happens. About 3 Minutes later I get the first deny by the packet filter: Dec 5 10:12:49 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.44 DST=217.82.186.42 LEN=1490 TOS=0x00 PREC=0x00 TTL=55 ID=16191 DF PROTO=TCP SPT=80 DPT=2764 WINDOW=31944 RES=0x00 ACK URGP=0 Dec 5 10:12:49 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.44 DST=217.82.186.42 LEN=54 TOS=0x00 PREC=0x00 TTL=55 ID=16192 DF PROTO=TCP SPT=80 DPT=2764 WINDOW=31944 RES=0x00 ACK PSH URGP=0 wich repeats for a while until the server gives up. Now does it still make sense to try, what you've told me to do? And what is the desease I'm curing with that? Thanks again, Ralf Ronneburger
On Wednesday 05 December 2001 11:32, Ralf Ronneburger wrote:
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. **********************************************************************
On Monday, 26. November 2001 10:31, you wrote:
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
On Monday 26 November 2001 10:31, Ralf Ronneburger wrote:
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:
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 <mss 1452,sackOK,timestamp 73022819 0,nop,wscale 0> (DF) 10:09:40.271757 213.83.12.10.http > 217.82.186.42.2764: S 3703832914:3703832914(0) ack 120893176 win 31944 <mss 1452,sackOK,timestamp 110780581 73022819,nop,wscale 0> (DF) 10:09:40.271973 217.82.186.42.2764 > 213.83.12.10.http: . ack 1 win 5808 <nop,nop,timestamp 73022824 110780581> (DF) 10:09:40.272986 217.82.186.42.2764 > 213.83.12.10.http: P 1:533(532) ack 1 win 5808 <nop,nop,timestamp 73022824 110780581> (DF) 10:09:40.343660 213.83.12.10.http > 217.82.186.42.2764: . ack 533 win 31944 <nop,nop,timestamp 110780589 73022824> (DF) But after the last reply of the server nothing happens. About 3 Minutes later I get the first deny by the packet filter: Dec 5 10:12:49 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.44 DST=217.82.186.42 LEN=1490 TOS=0x00 PREC=0x00 TTL=55 ID=16191 DF PROTO=TCP SPT=80 DPT=2764 WINDOW=31944 RES=0x00 ACK URGP=0 Dec 5 10:12:49 internet kernel: DROP-TCP IN=ppp0 OUT= MAC= SRC=213.83.13.44 DST=217.82.186.42 LEN=54 TOS=0x00 PREC=0x00 TTL=55 ID=16192 DF PROTO=TCP SPT=80 DPT=2764 WINDOW=31944 RES=0x00 ACK PSH URGP=0 wich repeats for a while until the server gives up. Now does it still make sense to try, what you've told me to do? And what is the desease I'm curing with that? Thanks again, Ralf Ronneburger
On Wednesday 05 December 2001 11:32, Ralf Ronneburger wrote:
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