Re: iptables + ipsec can't open an application

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 28, 2005 at 06:26:04PM -0200, Paulo Ricardo Bruck wrote:
> Hi guys
> 
> I've been testing debian sarge kernel 2.6.8-1 + iptables 1.2.11-8 +
> openswan 2.2.0-4 
> 
> I can ping from desktop1 to desktop2 , but if I try to see a http page
> at desktop1 from desktop 2 I see a connection time out.
> 
> desktop1-- iptables/openswan1--internet--iptables/openswan2--desktop2
> 
> ping 192.168.1.7 ( desktop 2)
> tcpdump from iptables2 wan
> IP 200.207.125.76 > 200.168.52.239: ESP(spi=0x78987d47,seq=0x22)
> IP 192.168.0.11 > 192.168.1.7: icmp 64: echo request seq 1
> IP 200.168.52.239 > 200.207.125.76: ESP(spi=0x1e76f500,seq=0x29)
> IP 200.207.125.76 > 200.168.52.239: ESP(spi=0x78987d47,seq=0x23)
> ok works
> 
> 
> lynx 192.168.1.7 (desktop2)
> tcpdump from iptables2 wan
> IP 200.207.125.76 > 200.168.52.239: ESP(spi=0x78987d47,seq=0x2c)
> IP 192.168.0.11.33654 > 192.168.1.7.80: S 3132491911:3132491911(0) win
> 5840 <mss 1460,sackOK,timestamp 33947617 0,nop,wscale 0>
> IP 200.168.52.239 > 200.207.125.76: ESP(spi=0x1e76f500,seq=0x39)
> IP 200.168.52.239 > 200.207.125.76: ESP(spi=0x1e76f500,seq=0x3a)
> IP 200.207.125.76 > 200.168.52.239: ESP(spi=0x78987d47,seq=0x2d)
> IP 192.168.0.11.33655 > 192.168.1.7.80: S 3148629414:3148629414(0) win
> 5840 <mss 1460,sackOK,timestamp 33950275 0,nop,wscale 0>
> IP 200.168.52.239 > 200.207.125.76: ESP(spi=0x1e76f500,seq=0x3b)
> IP 200.207.125.76 > 200.168.52.239: ESP(spi=0x78987d47,seq=0x2e)
> IP 192.168.0.11.33655 > 192.168.1.7.80: S 3148629414:3148629414(0) win
> 5840 <mss 1460,sackOK,timestamp 33953275 0,nop,wscale 0>
> 
> important rules iptables/ipsec1
> iptables -A INPUT   -p 50 -j ACCEPT
> iptables -A FORWARD -p 50 -j ACCEPT
> iptables -A INPUT   -p 51 -j ACCEPT
> iptables -A FORWARD -p 51 -j ACCEPT
> iptables -A INPUT   -p udp --sport 500 --dport 500 -j ACCEPT
> iptables -A INPUT   -p udp --sport 4500 --dport 4500 -j ACCEPT
> #iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss
> 1440
> iptables -A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
> iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT
> iptables -t nat -A POSTROUTING  -o $WAN1 -d ! 192.168.1.0/24 -j SNAT
> --to-source $IPWAN1
> 
> I ve already tried using TCPMSS, but not solved.

try it again, and use a lower value than 1440--i'd recommend starting
at 1400, actually--and work you're way down until it works.  i *would*
say tcpdump your external interface and filter for ICMP Type 3 Code 4
packets to verify that it's an MTU/MSS problem, but to quote a statement
some wizard just made in #iptables:

  "perhaps there is icmp filtering at the border router for anything not
   an echo reply.  which makes sense cause you normally dont need icmp
   messages across the internet"

depending on the combination of encapsulations in your specific scenario
(WiFi, PPP, etc), i've had to ratchet it down as low as 1330 to get a
functional tunnel.

-j

--
"The only reason I lied was because it was the easiest way to get
 what I wanted."
        --The Simpsons


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux