[strongSwan] StrongSWAN and AVM Fritzbox - Help!

Rene Bartsch ml at bartschnet.de
Sun Feb 13 17:49:35 CET 2011


After removing "leftfirewall=yes" from ipsec.conf and adding the incoming
FORWARD rule created by "leftfirewall=yes" to the INPUT chain manually, it
seems to work.

Is that a secure setup or is there any risk of sending plain packets?


*filter
:INPUT   DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT  ACCEPT [86:9176]

-A INPUT   -i lo                                                          
     -m comment --comment "ACCEPT loopback device"              -j ACCEPT
-A INPUT   -i dummy0                                                      
     -m comment --comment "ACCEPT dummy0 device"                -j ACCEPT
-A INPUT   -m state --state RELATED,ESTABLISHED                           
     -m comment --comment "ACCEPT existing connections"         -j ACCEPT

-A INPUT   -p icmp -m icmp --icmp-type echo-reply                         
     -m comment --comment "ACCEPT ICMP echo-reply"              -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type echo-request                       
     -m comment --comment "ACCEPT ICMP echo-request"            -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type time-exceeded                      
     -m comment --comment "ACCEPT ICMP time-exceeded"           -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type source-quench                      
     -m comment --comment "ACCEPT ICMP source-quench"           -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type port-unreachable                   
     -m comment --comment "ACCEPT ICMP port-unreachable"        -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type parameter-problem                  
     -m comment --comment "ACCEPT ICMP parameter-problem"       -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type fragmentation-needed               
     -m comment --comment "ACCEPT ICMP fragmentation-needed"    -j ACCEPT
-A INPUT   -p icmp -m icmp --icmp-type destination-unreachable            
     -m comment --comment "ACCEPT ICMP destination-unreachable" -j ACCEPT

###########################################################################################################################################################################

-A INPUT   -d xxx.xxx.xxx.102 -p esp                                      
     -m comment --comment "ACCEPT IPSec ESP"                    -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.102 -m policy --dir in --pol ipsec              
     -m comment --comment "ACCEPT IPSec secured packets"        -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.102 -p udp -m udp --dport 500                   
     -m comment --comment "ACCEPT IPSec IKE"                    -j ACCEPT
###-A INPUT   -d xxx.xxx.xxx.102 -p udp -m udp --dport 4500               
        -m comment --comment "ACCEPT IPSec NAT-T"                  -j
ACCEPT
-A INPUT   -s 192.168.177.0/24 -d 192.168.176.0/24 -m policy --dir in
--pol ipsec --reqid 16385 --proto esp -m comment --comment "ACCEPT IPSec
secured packets" -j ACCEPT

############################################################################################################################################################################


-A INPUT   -m state --state NEW -m recent --set --name DEFAULT --rsource  
     -m comment --comment "Store connection requests".
-A INPUT   -d xxx.xxx.xxx.102 -p tcp -m tcp --dport 22   -m state --state
NEW    -m recent --update --seconds 240 --hitcount 10 --name DEFAULT
--rsource -m comment --comment "DROP SSH Brute-Force-Attacks" -j DROP
-A INPUT   -d xxx.xxx.xxx.102 -p tcp -m tcp --dport 22   -m state --state
NEW    -m comment --comment "ACCEPT SSH connections"              -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.20  -p tcp -m tcp --dport 21   -m state --state
NEW    -m comment --comment "ACCEPT FTP connections"              -j ACCEPT
-A INPUT                      -p tcp -m tcp --dport 25   -m state --state
NEW    -m comment --comment "ACCEPT SMTP connections"             -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.20  -p udp -m udp --dport 53   -m state --state
NEW    -m comment --comment "ACCEPT DNS UDP connections"          -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.20  -p tcp -m tcp --dport 53   -m state --state
NEW    -m comment --comment "ACCEPT DNS TCP connections"          -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.20  -p tcp -m tcp --dport 80   -m state --state
NEW    -m comment --comment "ACCEPT HTTP connections"             -j ACCEPT
-A INPUT   -d xxx.xxx.xxx.20  -p tcp -m tcp --dport 443  -m state --state
NEW    -m comment --comment "ACCEPT HTTPS connections"            -j ACCEPT

COMMIT



Best regards,

Renne



On Sun, 13 Feb 2011 16:34:13 +0100, Rene Bartsch <ml at bartschnet.de> wrote:
> On Sat, 12 Feb 2011 16:42:42 -0800, Daniel Mentz
> <danielml+mailinglists.strongswan at sent.com> wrote:
>> On 02/12/2011 12:30 PM, Rene Bartsch wrote:
>>> My IPTables rules:
>>>
>>> *filter
>>> :INPUT   DROP [0:0]
>>> :FORWARD DROP [0:0]
>>> :OUTPUT  ACCEPT [86:9176]
>> 
>> Hi Rene,
>> 
>> not sure if this is relevant, but I think you're missing some iptables 
>> rules that allow the decrypted packets through. Your FORWARD chain is 
>> empty plus the default policy is DROP. Doesn't that mean that your box 
>> will decrypt the ESP packets but drop the payload shorty after?
>> 
>> Take a look at my setup
>> 
>> # IPsec
>> # Allow traffic from and to subnet 10.110.11.0/24 through the IPSec
> tunnel.
>> iptables -A FORWARD -s 10.110.11.0/24 -m policy --dir out --pol ipsec
-j
> 
>> ACCEPT
>> iptables -A FORWARD -d 10.110.11.0/24 -m policy --dir in --pol ipsec -j

>> ACCEPT
> 
> 
> The "leftfirewall=yes" option adds rules to FORWARD chain automatically
at
> IPSec handshake:
> 
> Chain FORWARD (policy DROP)
> target     prot opt source               destination         
> ACCEPT     all  --  192.168.177.0/24     192.168.176.0/24    policy
match
> dir in pol ipsec reqid 16385 proto esp 
> ACCEPT     all  --  192.168.176.0/24     192.168.177.0/24    policy
match
> dir out pol ipsec reqid 16385 proto esp
> 
> 
>> # Accept traffic secured by ipsec
>> iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT
> 
> Allows Ping, but no other packets like HTTP, ...
> 
> 
>> # Allow traffic through the IPSec tunnel.
>> iptables -A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT
> 
> Default policy "ACCEPT".
> 
>> # Do not mess with packets comming over IPSec
>> iptables -t nat -A PREROUTING -m policy --dir in --pol ipsec -j ACCEPT
>> iptables -t nat -A POSTROUTING -m policy --dir out --pol ipsec -j
ACCEPT
> 
> Fritzbox and Ubuntu server use public IPs for the IPSec daemons, NAT-T
may
> not be necessary.
>  
>> What were the results when troubleshooting using tcpdump? Can you 
>> configure iptables in a way such that it logs every dropped packet?
> 
> 
> I added a LOG target as last rule in INPUT and FORWARD chains. Trying a
> HTTP request with wget dropped the following packets:
> 
> Feb 13 16:15:30 www kernel: [155830.694973] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=10640 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:15:33 www kernel: [155833.701026] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=10641 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:15:39 www kernel: [155839.716271] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=10642 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:15:51 www kernel: [155851.749182] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=10643 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:16:15 www kernel: [155875.813376] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=10644 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:17:03 www kernel: [155923.877838] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=10645 DF PROTO=TCP SPT=39744 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:18:41 www kernel: [156021.008584] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=22169 DF PROTO=TCP SPT=53494 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:18:44 www kernel: [156024.015461] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=22170 DF PROTO=TCP SPT=53494 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> Feb 13 16:18:50 www kernel: [156030.023666] DROP INPUT:   IN=eth0 OUT=
> MAC=<myMAC> SRC=192.168.177.23 DST=192.168.176.1 LEN=60 TOS=0x00
PREC=0x00
> TTL=63 ID=22171 DF PROTO=TCP SPT=53494 DPT=80 WINDOW=5840 RES=0x00 SYN
> URGP=0
> 
> 
> But why in INPUT chain?
> 
> Best regards,
> 
> Renne
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users




More information about the Users mailing list