* ipsec with 2.6.16-rc3-git6
@ 2006-02-16 15:28 Marco Berizzi
2006-02-16 20:29 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Marco Berizzi @ 2006-02-16 15:28 UTC (permalink / raw)
To: netfilter-devel
I'm running openswan 2.4.5 with 2.6.16-rc3-git6 on
slackware 10.2 and I have a very strange problem.
I don't know if this is the desired behaviour or a
bug. I'm using iptables 1.3.5
With the following rules I was running ipsec
successfully with linux 2.6.15.1 to all our ipsec
gateway. After I have upgraded to 2.6.16-rc3-git6
I'm able to run ipsec only to venice_gateway.
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- venice_gateway 0.0.0.0/0
ACCEPT all -- 127.0.0.1 127.0.0.1
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
red-me all -- 0.0.0.0/0 0.0.0.0/0
Chain red-me (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3
0 0 ACCEPT esp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 500,4500
For now, I have workarounded the problem adding a rule for every ipsec
gateway,
but this is a problem for mobile users.
Chain INPUT (policy DROP 133 packets, 11320 bytes)
pkts bytes target prot opt in out source
destination
557 93608 ACCEPT all -- * * milano_gateay
0.0.0.0/0
313 31275 ACCEPT all -- * * venice_gateway
0.0.0.0/0
0 0 ACCEPT all -- * * 127.0.0.1
127.0.0.1
2 232 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
2 160 red-me all -- eth0 * 0.0.0.0/0
0.0.0.0/0
Chain red-me (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3
0 0 ACCEPT esp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 500,4500
Is this the correct behaviour?
FYI: tunnels are ESP+IPCOMP
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-16 15:28 ipsec with 2.6.16-rc3-git6 Marco Berizzi
@ 2006-02-16 20:29 ` Patrick McHardy
2006-02-17 8:33 ` Marco Berizzi
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2006-02-16 20:29 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netfilter-devel
Marco Berizzi wrote:
> I'm running openswan 2.4.5 with 2.6.16-rc3-git6 on
> slackware 10.2 and I have a very strange problem.
> I don't know if this is the desired behaviour or a
> bug. I'm using iptables 1.3.5
> With the following rules I was running ipsec
> successfully with linux 2.6.15.1 to all our ipsec
> gateway. After I have upgraded to 2.6.16-rc3-git6
> I'm able to run ipsec only to venice_gateway.
>
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- venice_gateway 0.0.0.0/0
> ACCEPT all -- 127.0.0.1 127.0.0.1
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
> RELATED,ESTABLISHED
> red-me all -- 0.0.0.0/0 0.0.0.0/0
>
> Chain red-me (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT icmp -- * * 0.0.0.0/0
> 0.0.0.0/0 icmp type 3
> 0 0 ACCEPT esp -- * * 0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT udp -- * * 0.0.0.0/0
> 0.0.0.0/0 multiport dports 500,4500
>
> For now, I have workarounded the problem adding a rule for every ipsec
> gateway,
> but this is a problem for mobile users.
2.6.16-rc includes patches for proper netfilter IPsec handling.
Packets will now go through the chains once in plain text and
once encrypted, so you need to adapt your ruleset. There is a
new "policy" match, which allows to match on packets from/to
IPsec tunnels, with that it should be relatively easy to create
rules for your roadwarriors.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-16 20:29 ` Patrick McHardy
@ 2006-02-17 8:33 ` Marco Berizzi
2006-02-17 8:53 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 8:33 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>2.6.16-rc includes patches for proper netfilter IPsec handling.
>Packets will now go through the chains once in plain text and
>once encrypted, so you need to adapt your ruleset. There is a
>new "policy" match, which allows to match on packets from/to
>IPsec tunnels, with that it should be relatively easy to create
>rules for your roadwarriors.
I didn't explain myself. Here is my network schema:
172.23.0.0/23===firenze-gateway..[ipsec
tunnel]..venezia-gateway===172.16.0.0/23
firenze-gateway is running 2.6.16-rc3-git6, and here is my rules:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- venezia-gateway 0.0.0.0/0
ACCEPT all -- 127.0.0.1 127.0.0.1
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
green-me all -- 172.23.0.0/23 0.0.0.0/0
dmz-me all -- 85.38.120.0/27 0.0.0.0/0
red-me all -- 0.0.0.0/0 0.0.0.0/0
Chain red-me (1 references)
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 3
ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 multiport
dports 500,4500
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT all -- 172.23.0.0/23 172.16.0.0/23
ACCEPT all -- 172.16.0.0/23 172.23.0.0/23
With these rules I'm able to send/receive packets from the two
private networks each other (172.16.0.0/23<->172.23.0.0/23).
If I delete the first rule in the INPUT table (on firenze-gateway)
ACCEPT all -- venezia-gateway 0.0.0.0/0
there is no packet flow inside the tunnel. I don't understand,
as I accept esp packets in the red-me chain.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 8:33 ` Marco Berizzi
@ 2006-02-17 8:53 ` Patrick McHardy
2006-02-17 8:58 ` Marco Berizzi
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2006-02-17 8:53 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netfilter-devel
Marco Berizzi wrote:
> With these rules I'm able to send/receive packets from the two
> private networks each other (172.16.0.0/23<->172.23.0.0/23).
> If I delete the first rule in the INPUT table (on firenze-gateway)
>
> ACCEPT all -- venezia-gateway 0.0.0.0/0
>
> there is no packet flow inside the tunnel. I don't understand,
> as I accept esp packets in the red-me chain.
What does your policy look like?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 8:53 ` Patrick McHardy
@ 2006-02-17 8:58 ` Marco Berizzi
2006-02-17 9:09 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 8:58 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>Marco Berizzi wrote:
> > With these rules I'm able to send/receive packets from the two
> > private networks each other (172.16.0.0/23<->172.23.0.0/23).
> > If I delete the first rule in the INPUT table (on firenze-gateway)
> >
> > ACCEPT all -- venezia-gateway 0.0.0.0/0
> >
> > there is no packet flow inside the tunnel. I don't understand,
> > as I accept esp packets in the red-me chain.
>
>What does your policy look like?
root@Halley:~# ip xfrm policy
src 172.16.0.0/23 dst 172.23.0.0/23
dir in priority 2377
tmpl src venezia-gateway dst firenze-gateway
proto comp reqid 16406 mode tunnel
level use
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16405 mode transport
src 172.23.0.0/23 dst 172.16.0.0/23
dir out priority 2377
tmpl src firenze-gateway dst venezia-gateway
proto comp reqid 16406 mode tunnel
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16405 mode transport
src 172.16.0.0/23 dst 172.23.0.0/23
dir fwd priority 2377
tmpl src venezia-gateway dst firenze-gateway
proto comp reqid 16406 mode tunnel
level use
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16405 mode transport
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 0
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 8:58 ` Marco Berizzi
@ 2006-02-17 9:09 ` Patrick McHardy
2006-02-17 9:26 ` Marco Berizzi
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2006-02-17 9:09 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netfilter-devel
Marco Berizzi wrote:
>
> Patrick McHardy wrote:
>
>> Marco Berizzi wrote:
>> > With these rules I'm able to send/receive packets from the two
>> > private networks each other (172.16.0.0/23<->172.23.0.0/23).
>> > If I delete the first rule in the INPUT table (on firenze-gateway)
>> >
>> > ACCEPT all -- venezia-gateway 0.0.0.0/0
>> >
>> > there is no packet flow inside the tunnel. I don't understand,
>> > as I accept esp packets in the red-me chain.
>>
>> What does your policy look like?
>
>
> root@Halley:~# ip xfrm policy
> src 172.16.0.0/23 dst 172.23.0.0/23
> dir in priority 2377
> tmpl src venezia-gateway dst firenze-gateway
> proto comp reqid 16406 mode tunnel
> level use
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 16405 mode transport
> src 172.23.0.0/23 dst 172.16.0.0/23
> dir out priority 2377
> tmpl src firenze-gateway dst venezia-gateway
> proto comp reqid 16406 mode tunnel
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 16405 mode transport
> src 172.16.0.0/23 dst 172.23.0.0/23
> dir fwd priority 2377
> tmpl src venezia-gateway dst firenze-gateway
> proto comp reqid 16406 mode tunnel
> level use
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 16405 mode transport
I can't see a mistake. Can you please add a logging rule to log
the packets that get dropped without the ACCEPT rule?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 9:09 ` Patrick McHardy
@ 2006-02-17 9:26 ` Marco Berizzi
2006-02-17 9:29 ` Patrick McHardy
0 siblings, 1 reply; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 9:26 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>Marco Berizzi wrote:
> >
> > Patrick McHardy wrote:
> >
> >> Marco Berizzi wrote:
> >> > With these rules I'm able to send/receive packets from the two
> >> > private networks each other (172.16.0.0/23<->172.23.0.0/23).
> >> > If I delete the first rule in the INPUT table (on firenze-gateway)
> >> >
> >> > ACCEPT all -- venezia-gateway 0.0.0.0/0
> >> >
> >> > there is no packet flow inside the tunnel. I don't understand,
> >> > as I accept esp packets in the red-me chain.
> >>
> >> What does your policy look like?
> >
> >
> > root@Halley:~# ip xfrm policy
> > src 172.16.0.0/23 dst 172.23.0.0/23
> > dir in priority 2377
> > tmpl src venezia-gateway dst firenze-gateway
> > proto comp reqid 16406 mode tunnel
> > level use
> > tmpl src 0.0.0.0 dst 0.0.0.0
> > proto esp reqid 16405 mode transport
> > src 172.23.0.0/23 dst 172.16.0.0/23
> > dir out priority 2377
> > tmpl src firenze-gateway dst venezia-gateway
> > proto comp reqid 16406 mode tunnel
> > tmpl src 0.0.0.0 dst 0.0.0.0
> > proto esp reqid 16405 mode transport
> > src 172.16.0.0/23 dst 172.23.0.0/23
> > dir fwd priority 2377
> > tmpl src venezia-gateway dst firenze-gateway
> > proto comp reqid 16406 mode tunnel
> > level use
> > tmpl src 0.0.0.0 dst 0.0.0.0
> > proto esp reqid 16405 mode transport
>
>I can't see a mistake. Can you please add a logging rule to log
>the packets that get dropped without the ACCEPT rule?
Sure! Here is:
root@Halley:/tmp# iptables -D INPUT -s venezia-gateway -j ACCEPT
[started ping from a venezia private host ----> to firenze private host]
root@Halley:/tmp# iptables -I INPUT -s venezia-gateway -j LOG --log-level
debug --log-ip-options
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45921 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45921 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45922 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45922 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45923 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45923 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45924 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45924 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45925 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45925 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45926 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45926 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45927 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45927 PROTO=4
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00 TTL=53
ID=45928 PROTO=ESP SPI=0x583f3ff9
IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
ID=45928 PROTO=4
root@Halley:/tmp# iptables -D INPUT -s venezia-gateway -j LOG --log-level
debug --log-ip-options
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 9:26 ` Marco Berizzi
@ 2006-02-17 9:29 ` Patrick McHardy
2006-02-17 9:57 ` Marco Berizzi
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Patrick McHardy @ 2006-02-17 9:29 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netfilter-devel
Marco Berizzi wrote:
>
> Patrick McHardy wrote:
>
>> I can't see a mistake. Can you please add a logging rule to log
>> the packets that get dropped without the ACCEPT rule?
>
>
> Sure! Here is:
>
> root@Halley:/tmp# iptables -D INPUT -s venezia-gateway -j ACCEPT
>
> [started ping from a venezia private host ----> to firenze private host]
>
> root@Halley:/tmp# iptables -I INPUT -s venezia-gateway -j LOG
> --log-level debug --log-ip-options
>
> IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00
> TTL=53 ID=45921 PROTO=ESP SPI=0x583f3ff9
> IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
> ID=45921 PROTO=4
Thats odd, these packets should be caught by your ESP rule, so I guess
they must be dropped by another rule. Please post your full ruleset with
iptables -vxnL.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 9:29 ` Patrick McHardy
@ 2006-02-17 9:57 ` Marco Berizzi
2006-02-17 10:07 ` Marco Berizzi
2006-02-17 10:11 ` Marco Berizzi
2 siblings, 0 replies; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 9:57 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>Marco Berizzi wrote:
> >
> > Patrick McHardy wrote:
> >
> >> I can't see a mistake. Can you please add a logging rule to log
> >> the packets that get dropped without the ACCEPT rule?
> >
> >
> > Sure! Here is:
> >
> > root@Halley:/tmp# iptables -D INPUT -s venezia-gateway -j ACCEPT
> >
> > [started ping from a venezia private host ----> to firenze private host]
> >
> > root@Halley:/tmp# iptables -I INPUT -s venezia-gateway -j LOG
> > --log-level debug --log-ip-options
> >
> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> > SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00
> > TTL=53 ID=45921 PROTO=ESP SPI=0x583f3ff9
> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> > SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
> > ID=45921 PROTO=4
>
>Thats odd, these packets should be caught by your ESP rule, so I guess
>they must be dropped by another rule. Please post your full ruleset with
>iptables -vxnL.
root@Halley:/tmp# iptables -vxnL
Chain INPUT (policy DROP 20200 packets, 2365881 bytes)
pkts bytes target prot opt in out source
destination
64008 21604598 ACCEPT all -- * * venezia-gateway
0.0.0.0/0
0 0 ACCEPT all -- * * 127.0.0.1
127.0.0.1
221 26259 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
14098 1492569 green-me all -- eth2 * 172.23.0.0/23
0.0.0.0/0
5787 840702 dmz-me all -- eth1 * firenze-dmz/27
0.0.0.0/0
302 27969 red-me all -- eth0 * 0.0.0.0/0
0.0.0.0/0
Chain FORWARD (policy DROP 3024 packets, 388141 bytes)
pkts bytes target prot opt in out source
destination
301354 107910370 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
1862 308821 ACCEPT all -- * * 172.23.0.0/23
172.16.0.0/23
705 59180 ACCEPT all -- * * 172.16.0.0/23
172.23.0.0/23
0 0 ACCEPT all -- * * 172.23.0.0/23
172.23.2.0/23
0 0 ACCEPT all -- * * 172.23.2.0/23
172.23.0.0/23
4055 518835 ACCEPT all -- * * 172.23.0.0/23
172.18.1.0/24
2812 767931 ACCEPT all -- * * 172.18.1.0/24
172.23.0.0/23
4 420 ACCEPT all -- * * 172.23.0.0/23
172.25.1.0/24
0 0 ACCEPT all -- * * 172.25.1.0/24
172.23.0.0/23
0 0 ACCEPT all -- * * 172.23.0.0/23
172.25.5.0/24
0 0 ACCEPT all -- * * 172.25.5.0/24
172.23.0.0/23
7 762 ACCEPT all -- * * 172.23.0.0/23
172.17.1.0/24
31 1860 ACCEPT all -- * * 172.17.1.0/24
172.23.0.0/23
0 0 ACCEPT all -- * * 172.23.0.0/23
172.22.1.0/24
0 0 ACCEPT all -- * * 172.22.1.0/24
172.23.0.0/23
7 762 ACCEPT all -- * * 172.23.0.0/23
172.21.1.0/24
0 0 ACCEPT all -- * * 172.21.1.0/24
172.23.0.0/23
1 60 green-red all -- eth2 eth0 172.23.0.0/23
0.0.0.0/0
0 0 green-dmz all -- eth2 eth1 172.23.0.0/23
firenze-dmz/27
42 2612 dmz-red all -- eth1 eth0 firenze-dmz/27
0.0.0.0/0
0 0 dmz-green all -- eth1 eth2 firenze-dmz/27
172.23.0.0/23
3023 388081 syn-flood-dmz all -- eth0 eth1 0.0.0.0/0
firenze-dmz/27
0 0 syn-flood-green all -- eth0 eth2 0.0.0.0/0
172.23.0.0/23
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 127.0.0.1
127.0.0.1
99249 31713374 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 me-green all -- * eth2 0.0.0.0/0
172.23.0.0/23
0 0 me-dmz all -- * eth1 0.0.0.0/0
firenze-dmz/27
159 30006 me-red all -- * eth0 0.0.0.0/0
0.0.0.0/0
Chain dmz-green (1 references)
pkts bytes target prot opt in out source
destination
0 0 icmp-me icmp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-unreachable
Chain dmz-me (1 references)
pkts bytes target prot opt in out source
destination
Chain dmz-red (1 references)
pkts bytes target prot opt in out source
destination
0 0 icmp-me icmp -- * * 0.0.0.0/0
0.0.0.0/0
37 2292 ACCEPT all -- * * firenze-dmz/27
venezia-dmz/27
Chain green-dmz (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain green-me (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 172.23.1.4
0.0.0.0/0 icmp type 8
Chain green-red (1 references)
pkts bytes target prot opt in out source
destination
Chain icmp-me (3 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 8
1 68 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3
Chain me-dmz (1 references)
pkts bytes target prot opt in out source
destination
Chain me-green (1 references)
pkts bytes target prot opt in out source
destination
Chain me-red (1 references)
pkts bytes target prot opt in out source
destination
1 68 icmp-me icmp -- * * 0.0.0.0/0
0.0.0.0/0
7 1136 ACCEPT esp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 53,123
151 28802 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 53,123,500,4500
Chain red-dmz (3 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * venezia-dmz/27
firenze-dmz/27
Chain red-green (3 references)
pkts bytes target prot opt in out source
destination
Chain red-me (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3
0 0 ACCEPT esp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 500,4500
Chain syn-flood-dmz (1 references)
pkts bytes target prot opt in out source
destination
1404 69840 red-dmz tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 1/sec burst 5
4 160 red-dmz tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 1/sec burst 5
806 278640 red-dmz udp -- * * 0.0.0.0/0
0.0.0.0/0
Chain syn-flood-green (1 references)
pkts bytes target prot opt in out source
destination
0 0 red-green tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 20/min burst 5
0 0 red-green tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 20/min burst 5
0 0 red-green udp -- * * 0.0.0.0/0
0.0.0.0/0
root@Halley:/tmp#
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 9:29 ` Patrick McHardy
2006-02-17 9:57 ` Marco Berizzi
@ 2006-02-17 10:07 ` Marco Berizzi
2006-02-17 10:11 ` Marco Berizzi
2 siblings, 0 replies; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 10:07 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>Marco Berizzi wrote:
> >
> > Patrick McHardy wrote:
> >
> >> I can't see a mistake. Can you please add a logging rule to log
> >> the packets that get dropped without the ACCEPT rule?
> >
> >
> > Sure! Here is:
> >
> > root@Halley:/tmp# iptables -D INPUT -s venezia-gateway -j ACCEPT
> >
> > [started ping from a venezia private host ----> to firenze private host]
> >
> > root@Halley:/tmp# iptables -I INPUT -s venezia-gateway -j LOG
> > --log-level debug --log-ip-options
> >
> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> > SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00
> > TTL=53 ID=45921 PROTO=ESP SPI=0x583f3ff9
> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> > SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
> > ID=45921 PROTO=4
>
>Thats odd, these packets should be caught by your ESP rule, so I guess
>they must be dropped by another rule. Please post your full ruleset with
>iptables -vxnL.
Patrick,
Also adding this rule is not sufficient:
iptables -I INPUT -s venezia-gateway --protocol esp -j ACCEPT
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 9:29 ` Patrick McHardy
2006-02-17 9:57 ` Marco Berizzi
2006-02-17 10:07 ` Marco Berizzi
@ 2006-02-17 10:11 ` Marco Berizzi
2006-02-17 10:15 ` Patrick McHardy
2 siblings, 1 reply; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 10:11 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>Marco Berizzi wrote:
> >
> > Patrick McHardy wrote:
> >
> >> I can't see a mistake. Can you please add a logging rule to log
> >> the packets that get dropped without the ACCEPT rule?
> >
> >
> > Sure! Here is:
> >
> > root@Halley:/tmp# iptables -D INPUT -s venezia-gateway -j ACCEPT
> >
> > [started ping from a venezia private host ----> to firenze private host]
> >
> > root@Halley:/tmp# iptables -I INPUT -s venezia-gateway -j LOG
> > --log-level debug --log-ip-options
> >
> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> > SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00
> > TTL=53 ID=45921 PROTO=ESP SPI=0x583f3ff9
> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> > SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00 TTL=53
> > ID=45921 PROTO=4
>
>Thats odd, these packets should be caught by your ESP rule, so I guess
>they must be dropped by another rule. Please post your full ruleset with
>iptables -vxnL.
Me again. Aha! Found!!! ;-))
iptables -I INPUT -s venice-gateway --protocol 4 -j ACCEPT
did the trick.
Patrick, thanks a lot for the feedback.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 10:11 ` Marco Berizzi
@ 2006-02-17 10:15 ` Patrick McHardy
2006-02-17 10:35 ` Marco Berizzi
0 siblings, 1 reply; 13+ messages in thread
From: Patrick McHardy @ 2006-02-17 10:15 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netfilter-devel
Marco Berizzi wrote:
>
>> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
>> > SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00
>> > TTL=53 ID=45921 PROTO=ESP SPI=0x583f3ff9
>> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
>> > SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00
>> TTL=53
>> > ID=45921 PROTO=4
>>
>> Thats odd, these packets should be caught by your ESP rule, so I guess
>> they must be dropped by another rule. Please post your full ruleset with
>> iptables -vxnL.
>
>
> Me again. Aha! Found!!! ;-))
>
> iptables -I INPUT -s venice-gateway --protocol 4 -j ACCEPT
>
> did the trick.
I also just noticed the second line contains IPCOMP not ESP, which is
strange because ESP is used in transport mode, so the ESP and IPCOMP
decapsulation should happen without any netfilter hooks in between.
src 172.16.0.0/23 dst 172.23.0.0/23
dir in priority 2377
tmpl src venezia-gateway dst firenze-gateway
proto comp reqid 16406 mode tunnel
level use
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16405 mode transport
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ipsec with 2.6.16-rc3-git6
2006-02-17 10:15 ` Patrick McHardy
@ 2006-02-17 10:35 ` Marco Berizzi
0 siblings, 0 replies; 13+ messages in thread
From: Marco Berizzi @ 2006-02-17 10:35 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel
Patrick McHardy wrote:
>Marco Berizzi wrote:
> >
> >> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> >> > SRC=venezia-gateway DST=firenze-gateway LEN=112 TOS=0x00 PREC=0x00
> >> > TTL=53 ID=45921 PROTO=ESP SPI=0x583f3ff9
> >> > IN=eth0 OUT= MAC=00:90:27:74:66:4c:00:0c:ce:93:65:ce:08:00
> >> > SRC=venezia-gateway DST=firenze-gateway LEN=80 TOS=0x00 PREC=0x00
> >> TTL=53
> >> > ID=45921 PROTO=4
> >>
> >> Thats odd, these packets should be caught by your ESP rule, so I guess
> >> they must be dropped by another rule. Please post your full ruleset
>with
> >> iptables -vxnL.
> >
> >
> > Me again. Aha! Found!!! ;-))
> >
> > iptables -I INPUT -s venice-gateway --protocol 4 -j ACCEPT
> >
> > did the trick.
>
>I also just noticed the second line contains IPCOMP not ESP, which is
>strange because ESP is used in transport mode, so the ESP and IPCOMP
>decapsulation should happen without any netfilter hooks in between.
>
>src 172.16.0.0/23 dst 172.23.0.0/23
> dir in priority 2377
> tmpl src venezia-gateway dst firenze-gateway
> proto comp reqid 16406 mode tunnel
> level use
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 16405 mode transport
>
This behaviour happens only for the INPUT chain. I didn't insert
a rule for the output chain to permit protocol 4.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2006-02-17 10:35 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-16 15:28 ipsec with 2.6.16-rc3-git6 Marco Berizzi
2006-02-16 20:29 ` Patrick McHardy
2006-02-17 8:33 ` Marco Berizzi
2006-02-17 8:53 ` Patrick McHardy
2006-02-17 8:58 ` Marco Berizzi
2006-02-17 9:09 ` Patrick McHardy
2006-02-17 9:26 ` Marco Berizzi
2006-02-17 9:29 ` Patrick McHardy
2006-02-17 9:57 ` Marco Berizzi
2006-02-17 10:07 ` Marco Berizzi
2006-02-17 10:11 ` Marco Berizzi
2006-02-17 10:15 ` Patrick McHardy
2006-02-17 10:35 ` Marco Berizzi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.