From: reydecopas <rey...@gm...> - 2006-01-25 15:13:05
|
I have made a classical lan-to-lan ipsec VPN lanA--------GW_A=3D=3D=3D=3D=3DGW_B----lanB Every thing works perfectly. But now I want that lanA could access to lanB servers but not lanB to lanA When I active iptables on GW_A to avoid than lan_B could access to lan_servers, the sentence "iptables -A RH-Lokkit-0-50-INPUT -j REJECT" send an icmp port unreachable (with dst_addr =3D=3D lanB client) OUTSIDE the tunnel ipsec (in plain text)= so this packet doesn't reach lanB. And if a client from lanB tries to access to a server on lanA, the connection leave waiting till the timeout. Sorry for my bad english... I think that this packet crafted by iptables is bypassing the ipsec policie= s established with setkey. Is this a bug? here is the iptables-save from GW_A # Generated by iptables-save v1.2.11 on Wed Jan 25 17:09:55 2006 *nat :PREROUTING ACCEPT [2:488] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Wed Jan 25 17:09:55 2006 # Generated by iptables-save v1.2.11 on Wed Jan 25 17:09:55 2006 *filter :INPUT ACCEPT [88:7289] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [88:8353] :RH-Lokkit-0-50-INPUT - [0:0] -A INPUT -j RH-Lokkit-0-50-INPUT -A FORWARD -j RH-Lokkit-0-50-INPUT -A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT -A RH-Lokkit-0-50-INPUT -i eth1 -j ACCEPT -A RH-Lokkit-0-50-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Lokkit-0-50-INPUT -p esp -j ACCEPT -A RH-Lokkit-0-50-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Lokkit-0-50-INPUT -j REJECT --reject-with icmp-port-unreachable COMMIT # Completed on Wed Jan 25 17:09:55 2006 and my ipsec-tools.conf on GW_A spdadd lanA lanB any -P out ipsec esp/tunnel/GW_A-GW_B/require; spdadd lanB lanA any -P in ipsec esp/tunnel/GW_B-GW_A/require; I'm runnig Debian sarge. |
From: Brian C. <B.C...@po...> - 2006-01-25 16:46:27
|
On Wed, Jan 25, 2006 at 04:13:00PM +0100, reydecopas wrote: > I have made a classical lan-to-lan ipsec VPN > lanA--------GW_A=====GW_B----lanB > Every thing works perfectly. > But now I want that lanA could access to lanB servers but not lanB to > lanA > When I active iptables on GW_A to avoid than lan_B could access to > lan_servers, the sentence > "iptables -A RH-Lokkit-0-50-INPUT -j REJECT" send an icmp port > unreachable (with dst_addr == lanB client) OUTSIDE the tunnel ipsec > (in plain text) so this packet doesn't reach lanB. But the source address of this packet will be GW_A's external IP address. Have you got a security policy in place for IPSEC encrypting traffic with a source of GW_A(ext) and dest of lanB? > and my ipsec-tools.conf on GW_A > spdadd lanA lanB any -P out ipsec > esp/tunnel/GW_A-GW_B/require; > spdadd lanB lanA any -P in ipsec > esp/tunnel/GW_B-GW_A/require; It looks like you don't. I think you'll need extra policy/ies for this. Regards, Brian. |
From: reydecopas <rey...@gm...> - 2006-01-26 12:36:37
|
>But the source address of this packet will be GW_A's external IP address. >Have you got a security policy in place for IPSEC encrypting traffic with = a >source of GW_A(ext) and dest of lanB? The source address of this packet is the lanA ip address which was the destiny of the original packet, though this packet is generated in GW_A, is generated by "iptables -Reject" in this way. So this packet match with the policy (src_address is lanA and dst_address i= s lanB). I noticed that with tcpdump... What I see is that this packet generated by iptables is bypassing the policies If I remove iptables from GW_A and I put the same rules on the server on lanA it works perfectly, because the packet is the same but generated in a machine inside the lanA behind the GW_A, which sends it into the TUNNEL so it=B4s not a mismatch of policies. I think it has to be something related with level of the priority in the tcp/ip stack between setkey policie= s and iptables chains Thank for your comments Regards On 1/25/06, Brian Candler <B.C...@po...> wrote: > > On Wed, Jan 25, 2006 at 04:13:00PM +0100, reydecopas wrote: > > I have made a classical lan-to-lan ipsec VPN > > lanA--------GW_A=3D=3D=3D=3D=3DGW_B----lanB > > Every thing works perfectly. > > But now I want that lanA could access to lanB servers but not lanB t= o > > lanA > > When I active iptables on GW_A to avoid than lan_B could access to > > lan_servers, the sentence > > "iptables -A RH-Lokkit-0-50-INPUT -j REJECT" send an icmp port > > unreachable (with dst_addr =3D=3D lanB client) OUTSIDE the tunnel ip= sec > > (in plain text) so this packet doesn't reach lanB. > > But the source address of this packet will be GW_A's external IP address. > Have you got a security policy in place for IPSEC encrypting traffic with > a > source of GW_A(ext) and dest of lanB? > > > and my ipsec-tools.conf on GW_A > > spdadd lanA lanB any -P out ipsec > > esp/tunnel/GW_A-GW_B/require; > > spdadd lanB lanA any -P in ipsec > > esp/tunnel/GW_B-GW_A/require; > > It looks like you don't. I think you'll need extra policy/ies for this. > > Regards, Brian. > |
From: Patrick M. <ka...@tr...> - 2006-01-27 09:16:46
|
reydecopas wrote: >>But the source address of this packet will be GW_A's external IP addres= s. >>Have you got a security policy in place for IPSEC encrypting traffic wi= th a >>source of GW_A(ext) and dest of lanB? >=20 >=20 > The source address of this packet is the lanA ip address which was the > destiny of the original packet, > though this packet is generated in GW_A, is generated by "iptables -Rej= ect" > in this way. > So this packet match with the policy (src_address is lanA and dst_addre= ss is > lanB). I noticed that with tcpdump... >=20 > What I see is that this packet generated by iptables is bypassing the > policies >=20 > If I remove iptables from GW_A and I put the same rules on the server o= n > lanA it works perfectly, because the packet is the same but generated i= n a > machine inside the lanA behind the GW_A, which sends it into the TUNNE= L so > it=B4s not a mismatch of policies. I think it has to be something rela= ted > with level of the priority in the tcp/ip stack between setkey pol= icies > and iptables chains Older linux versions had a bug that made packets generated by ipt_REJECT bypass IPsec. Current versions of the kernel should work fine. |
From: reydecopas <rey...@gm...> - 2006-01-27 12:16:55
|
I will try a newer version, thank you On 1/27/06, Patrick McHardy <ka...@tr...> wrote: > > reydecopas wrote: > >>But the source address of this packet will be GW_A's external IP > address. > >>Have you got a security policy in place for IPSEC encrypting traffic > with a > >>source of GW_A(ext) and dest of lanB? > > > > > > The source address of this packet is the lanA ip address which was the > > destiny of the original packet, > > though this packet is generated in GW_A, is generated by "iptables > -Reject" > > in this way. > > So this packet match with the policy (src_address is lanA and > dst_address is > > lanB). I noticed that with tcpdump... > > > > What I see is that this packet generated by iptables is bypassing the > > policies > > > > If I remove iptables from GW_A and I put the same rules on the server o= n > > lanA it works perfectly, because the packet is the same but generated i= n > a > > machine inside the lanA behind the GW_A, which sends it into the TUNNE= L > so > > it=B4s not a mismatch of policies. I think it has to be something rela= ted > > with level of the priority in the tcp/ip stack between setkey > policies > > and iptables chains > > Older linux versions had a bug that made packets generated by ipt_REJECT > bypass IPsec. Current versions of the kernel should work fine. > |