* Reject non-ipsec traffic
@ 2011-07-20 19:20 Ryan Whelan
2011-07-20 19:56 ` Jan Engelhardt
0 siblings, 1 reply; 15+ messages in thread
From: Ryan Whelan @ 2011-07-20 19:20 UTC (permalink / raw)
To: netfilter
I have IPSec setup between 2 hosts and would like to stop all
inter-host traffic thats not secured with IPSec (They have a GRE
tunnel between them, and I want to be sure the GRE traffic fails to
transmit if the IPSec daemon fails)
I'm testing from host hostA, trying to ping hostB.
This is what I've tried; allow only output traffic thats part of IPSec
to hostB. Else, reject it
iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
iptables -A OUTPUT -d hostB.example.com -j REJECT
[root@hostA ~]# iptables -vL
Chain INPUT (policy ACCEPT 124 packets, 9920 bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 94 packets, 12768 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT udp -- any any anywhere
hostB.example.com udp dpt:isakmp
0 0 ACCEPT tcp -- any any anywhere
hostB.example.com tcp dpt:isakmp
0 0 ACCEPT esp -- any any anywhere
hostB.example.com
8 864 REJECT all -- any any anywhere
hostB.example.com reject-with icmp-port-unreachable
[root@hostA ~]#
The reject rule is rejecting all traffic to that host as you can see
from the pkt counter. If i remove that rule, everything works and i
see the packets get counted on the ESP protocol rule. I thought the
rules were processes in order until a match was found. Clearly I'm
wrong.
Is this possible without much complexity?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-20 19:20 Reject non-ipsec traffic Ryan Whelan
@ 2011-07-20 19:56 ` Jan Engelhardt
2011-07-20 20:13 ` Ryan Whelan
0 siblings, 1 reply; 15+ messages in thread
From: Jan Engelhardt @ 2011-07-20 19:56 UTC (permalink / raw)
To: Ryan Whelan; +Cc: netfilter
On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>I have IPSec setup between 2 hosts and would like to stop all
>inter-host traffic thats not secured with IPSec (They have a GRE
>tunnel between them, and I want to be sure the GRE traffic fails to
>transmit if the IPSec daemon fails)
>
>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>iptables -A OUTPUT -d hostB.example.com -j REJECT
>
>The reject rule is rejecting all traffic to that host[...]
>If i remove that rule, everything works and i
>see the packets get counted on the ESP protocol rule. I thought the
>rules were processes in order until a match was found. Clearly I'm
>wrong.
They are indeed processed in order, and until a match is found --
and match _was_ found (packet which has dst=hostB, which is not
ESP, and which does not have tcpudp-500 in its headers).
A `ping hostB` would match the criteria of this 4th rules, as would
opening http://hostB.example.com in a browser, for example.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-20 19:56 ` Jan Engelhardt
@ 2011-07-20 20:13 ` Ryan Whelan
2011-07-20 20:30 ` Jan Engelhardt
0 siblings, 1 reply; 15+ messages in thread
From: Ryan Whelan @ 2011-07-20 20:13 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
On Wed, Jul 20, 2011 at 3:56 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>
>>I have IPSec setup between 2 hosts and would like to stop all
>>inter-host traffic thats not secured with IPSec (They have a GRE
>>tunnel between them, and I want to be sure the GRE traffic fails to
>>transmit if the IPSec daemon fails)
>>
>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>
>>The reject rule is rejecting all traffic to that host[...]
>>If i remove that rule, everything works and i
>>see the packets get counted on the ESP protocol rule. I thought the
>>rules were processes in order until a match was found. Clearly I'm
>>wrong.
>
> They are indeed processed in order, and until a match is found --
> and match _was_ found (packet which has dst=hostB, which is not
> ESP, and which does not have tcpudp-500 in its headers).
>
> A `ping hostB` would match the criteria of this 4th rules, as would
> opening http://hostB.example.com in a browser, for example.
>
but if i remove that the last rule, the 3 rule starts counting matches
(the ESP protocol rule). If that rule matches, why does it continue to
look at rule 4 if rule 3 matches?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-20 20:13 ` Ryan Whelan
@ 2011-07-20 20:30 ` Jan Engelhardt
2011-07-20 20:33 ` Ryan Whelan
0 siblings, 1 reply; 15+ messages in thread
From: Jan Engelhardt @ 2011-07-20 20:30 UTC (permalink / raw)
To: Ryan Whelan; +Cc: netfilter
On Wednesday 2011-07-20 22:13, Ryan Whelan wrote:
>On Wed, Jul 20, 2011 at 3:56 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>> On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>>
>>>I have IPSec setup between 2 hosts and would like to stop all
>>>inter-host traffic thats not secured with IPSec (They have a GRE
>>>tunnel between them, and I want to be sure the GRE traffic fails to
>>>transmit if the IPSec daemon fails)
>>>
>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>
>>>The reject rule is rejecting all traffic to that host[...]
>>>If i remove that rule, everything works and i
>>>see the packets get counted on the ESP protocol rule. I thought the
>>>rules were processes in order until a match was found. Clearly I'm
>>>wrong.
>>
>> They are indeed processed in order, and until a match is found --
>> and match _was_ found (packet which has dst=hostB, which is not
>> ESP, and which does not have tcpudp-500 in its headers).
>>
>> A `ping hostB` would match the criteria of this 4th rules, as would
>> opening http://hostB.example.com in a browser, for example.
>
>but if i remove that the last rule, the 3 rule starts counting matches
>(the ESP protocol rule).
Sure, because once you are not dropping the original packet in rule
4, it has a chance to get encrypted, show up as ESP, and match rule
3.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-20 20:30 ` Jan Engelhardt
@ 2011-07-20 20:33 ` Ryan Whelan
2011-07-20 20:34 ` Jan Engelhardt
0 siblings, 1 reply; 15+ messages in thread
From: Ryan Whelan @ 2011-07-20 20:33 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
On Wed, Jul 20, 2011 at 4:30 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2011-07-20 22:13, Ryan Whelan wrote:
>>On Wed, Jul 20, 2011 at 3:56 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>>> On Wednesday 2011-07-20 21:20, Ryan Whelan wrote:
>>>
>>>>I have IPSec setup between 2 hosts and would like to stop all
>>>>inter-host traffic thats not secured with IPSec (They have a GRE
>>>>tunnel between them, and I want to be sure the GRE traffic fails to
>>>>transmit if the IPSec daemon fails)
>>>>
>>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>>
>>>>The reject rule is rejecting all traffic to that host[...]
>>>>If i remove that rule, everything works and i
>>>>see the packets get counted on the ESP protocol rule. I thought the
>>>>rules were processes in order until a match was found. Clearly I'm
>>>>wrong.
>>>
>>> They are indeed processed in order, and until a match is found --
>>> and match _was_ found (packet which has dst=hostB, which is not
>>> ESP, and which does not have tcpudp-500 in its headers).
>>>
>>> A `ping hostB` would match the criteria of this 4th rules, as would
>>> opening http://hostB.example.com in a browser, for example.
>>
>>but if i remove that the last rule, the 3 rule starts counting matches
>>(the ESP protocol rule).
>
> Sure, because once you are not dropping the original packet in rule
> 4, it has a chance to get encrypted, show up as ESP, and match rule
> 3.
>
So the outbound traffic is being processed by netfilter before getting
wrapped by IPSec?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-20 20:33 ` Ryan Whelan
@ 2011-07-20 20:34 ` Jan Engelhardt
2011-07-21 0:09 ` Ryan Whelan
0 siblings, 1 reply; 15+ messages in thread
From: Jan Engelhardt @ 2011-07-20 20:34 UTC (permalink / raw)
To: Ryan Whelan; +Cc: netfilter
On Wednesday 2011-07-20 22:33, Ryan Whelan wrote:
>>>
>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>
>>>but if i remove that the last rule, the 3 rule starts counting matches
>>>(the ESP protocol rule).
>>
>> Sure, because once you are not dropping the original packet in rule
>> 4, it has a chance to get encrypted, show up as ESP, and match rule
>> 3.
>
>So the outbound traffic is being processed by netfilter before getting
>wrapped by IPSec?
Both before and after.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-20 20:34 ` Jan Engelhardt
@ 2011-07-21 0:09 ` Ryan Whelan
2011-07-21 16:55 ` Petr Pisar
2011-07-25 0:47 ` Jan Engelhardt
0 siblings, 2 replies; 15+ messages in thread
From: Ryan Whelan @ 2011-07-21 0:09 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter
On Wed, Jul 20, 2011 at 4:34 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Wednesday 2011-07-20 22:33, Ryan Whelan wrote:
>>>>
>>>>iptables -A OUTPUT -p udp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p tcp --dport 500 -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -p esp -d hostB.example.com -j ACCEPT
>>>>iptables -A OUTPUT -d hostB.example.com -j REJECT
>>>>
>>>>but if i remove that the last rule, the 3 rule starts counting matches
>>>>(the ESP protocol rule).
>>>
>>> Sure, because once you are not dropping the original packet in rule
>>> 4, it has a chance to get encrypted, show up as ESP, and match rule
>>> 3.
>>
>>So the outbound traffic is being processed by netfilter before getting
>>wrapped by IPSec?
>
> Both before and after.
>
Is there a way to accomplish this? Maybe a way to only accept a
non-esp packets if it destined for the ipsec stack; is that possible?
The only other recourse I can think of is dropping on the receiving
side any non-esp packets. Thats better than nothing, but I'd like to
not send anything unencrypted if possible.
These machines will be forwarding more traffic than they originate.
Should I put this filtering on the `mangle` to catch both forwarded
and sent packets?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-21 0:09 ` Ryan Whelan
@ 2011-07-21 16:55 ` Petr Pisar
2011-07-21 17:05 ` Ryan Whelan
2011-07-25 0:47 ` Jan Engelhardt
1 sibling, 1 reply; 15+ messages in thread
From: Petr Pisar @ 2011-07-21 16:55 UTC (permalink / raw)
To: netfilter
On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
>
> Is there a way to accomplish this? Maybe a way to only accept a
> non-esp packets if it destined for the ipsec stack; is that possible?
I know you ask about netfilter, but consider IPsec security policies
(defined by setkey tool) can be used to force xfrm based on network or
transport source or destinatino addresses.
-- Petr
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-21 16:55 ` Petr Pisar
@ 2011-07-21 17:05 ` Ryan Whelan
2011-07-21 19:01 ` Steven Kath
2011-07-22 5:15 ` Petr Pisar
0 siblings, 2 replies; 15+ messages in thread
From: Ryan Whelan @ 2011-07-21 17:05 UTC (permalink / raw)
To: Petr Pisar; +Cc: netfilter
The policy is setup (openswan configures it)
# ip xfrm poli
src 111.222.333.444/32 dst 444.333.222.111/32 proto gre
dir out priority 2080
tmpl src 111.222.333.444 dst 444.333.222.111
proto esp reqid 16385 mode tunnel
src 444.333.222.111/32 dst 111.222.333.444/32 proto gre
dir fwd priority 2080
tmpl src 444.333.222.111 dst 111.222.333.444
proto esp reqid 16385 mode tunnel
The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
for some reason, GRE will be happy to work without it; tunnelling
everything in the clear. I was just hoping to put some kind of fail
safe in place so if IPSec stopped working or failed to start,
unencrypted traffic wouldn't be transmitted.
I will try putting a filter on the ingress side to reject all GRE
traffic so if it not tunneled in IPSec, it will get dropped. At least
that way, tunnelled TCP sessions can't get setup.
On Thu, Jul 21, 2011 at 12:55 PM, Petr Pisar <petr.pisar@atlas.cz> wrote:
> On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
>>
>> Is there a way to accomplish this? Maybe a way to only accept a
>> non-esp packets if it destined for the ipsec stack; is that possible?
>
> I know you ask about netfilter, but consider IPsec security policies
> (defined by setkey tool) can be used to force xfrm based on network or
> transport source or destinatino addresses.
>
> -- Petr
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-21 17:05 ` Ryan Whelan
@ 2011-07-21 19:01 ` Steven Kath
2011-07-21 19:29 ` Jan Engelhardt
2011-07-22 5:15 ` Petr Pisar
1 sibling, 1 reply; 15+ messages in thread
From: Steven Kath @ 2011-07-21 19:01 UTC (permalink / raw)
To: Ryan Whelan; +Cc: Petr Pisar, netfilter
On Thu, 2011-07-21 at 13:05 -0400, Ryan Whelan wrote:
> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
> for some reason, GRE will be happy to work without it; tunnelling
> everything in the clear. I was just hoping to put some kind of fail
> safe in place so if IPSec stopped working or failed to start,
> unencrypted traffic wouldn't be transmitted.
You could create a private loopback address on each endpoint, and use
those loopback addresses in the encryption policy. The only way the
loopback addresses can reach each other is while the IPsec associations
are up. Then set up the GRE tunnel with the loopbacks as its endpoints.
That way, when the IPsec tunnel is down, GRE will no longer be happy to
work without it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-21 19:01 ` Steven Kath
@ 2011-07-21 19:29 ` Jan Engelhardt
0 siblings, 0 replies; 15+ messages in thread
From: Jan Engelhardt @ 2011-07-21 19:29 UTC (permalink / raw)
To: Steven Kath; +Cc: Ryan Whelan, Petr Pisar, netfilter
On Thursday 2011-07-21 21:01, Steven Kath wrote:
>On Thu, 2011-07-21 at 13:05 -0400, Ryan Whelan wrote:
>> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
>> for some reason, GRE will be happy to work without it; tunnelling
>> everything in the clear. I was just hoping to put some kind of fail
>> safe in place so if IPSec stopped working or failed to start,
>> unencrypted traffic wouldn't be transmitted.
>
>You could create a private loopback address on each endpoint, and use
>those loopback addresses in the encryption policy. The only way the
>loopback addresses can reach each other is while the IPsec associations
>are up. Then set up the GRE tunnel with the loopbacks as its endpoints.
>That way, when the IPsec tunnel is down, GRE will no longer be happy to
>work without it.
What I thought of was the use of veth, such that you have a way to
distinguish between a packet that remained unencrypted, or one that is
yet to possibly get encrypted.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-21 17:05 ` Ryan Whelan
2011-07-21 19:01 ` Steven Kath
@ 2011-07-22 5:15 ` Petr Pisar
2011-07-24 22:40 ` Greg Scott
1 sibling, 1 reply; 15+ messages in thread
From: Petr Pisar @ 2011-07-22 5:15 UTC (permalink / raw)
To: netfilter
On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
> The policy is setup (openswan configures it)
>
> # ip xfrm poli
> src 111.222.333.444/32 dst 444.333.222.111/32 proto gre
> dir out priority 2080
> tmpl src 111.222.333.444 dst 444.333.222.111
> proto esp reqid 16385 mode tunnel
> src 444.333.222.111/32 dst 111.222.333.444/32 proto gre
> dir fwd priority 2080
> tmpl src 444.333.222.111 dst 111.222.333.444
> proto esp reqid 16385 mode tunnel
>
I don't know openswan syntax. setkey syntax provides level `require'
which means if security association is missing, the packet will not be
sent. I guess the openswan `reqid' is the same as setkey `unique' which
is the same as `require' bound to specific security association.
Please note the security policies can be loaded into kernel independently
on IKE daemon, so you are guarded even if daemon does not start.
> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
> for some reason, GRE will be happy to work without it; tunnelling
> everything in the clear. I was just hoping to put some kind of fail
> safe in place so if IPSec stopped working or failed to start,
> unencrypted traffic wouldn't be transmitted.
>
I see, another independent meassure. Unfortunatelly you are out of luck
in case of netfilter on egress traffic.
-- Petr
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Reject non-ipsec traffic
2011-07-22 5:15 ` Petr Pisar
@ 2011-07-24 22:40 ` Greg Scott
2011-07-25 0:32 ` Jan Engelhardt
0 siblings, 1 reply; 15+ messages in thread
From: Greg Scott @ 2011-07-24 22:40 UTC (permalink / raw)
To: netfilter; +Cc: Ryan Whelan, Petr Pisar, Jan Engelhardt
But wait a minute - something else has gotta be going on here. The
original rules had an ACCEPT for UDP and TCP port 500 and then for ESP
and AH. And then the DROP all rule. When the drop all rule is removed,
then everything comes through because the packet does its thing, gets
re-injected, and now it's ESP.
So that original packet must be something other than UDP 500 - right?
Something else must happen during the original handshake setting up the
IPSEC SA - because if it was all UDP 500, you'd ACCEPT it - right? I
think I kind of remember some UDP port 4500 stuff gets in the act
somehow. Before getting too fancy, maybe insert a -J LOG rule right in
front of that DROP rule so you can see what you're dropping. That might
give some clues.
- Greg Scott
-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of Petr Pisar
Sent: Friday, July 22, 2011 12:15 AM
To: netfilter@vger.kernel.org
Subject: Re: Reject non-ipsec traffic
On 2011-07-21, Ryan Whelan <rcwhelan@gmail.com> wrote:
> The policy is setup (openswan configures it)
>
> # ip xfrm poli
> src 111.222.333.444/32 dst 444.333.222.111/32 proto gre
> dir out priority 2080
> tmpl src 111.222.333.444 dst 444.333.222.111
> proto esp reqid 16385 mode tunnel
> src 444.333.222.111/32 dst 111.222.333.444/32 proto gre
> dir fwd priority 2080
> tmpl src 444.333.222.111 dst 111.222.333.444
> proto esp reqid 16385 mode tunnel
>
I don't know openswan syntax. setkey syntax provides level `require'
which means if security association is missing, the packet will not be
sent. I guess the openswan `reqid' is the same as setkey `unique' which
is the same as `require' bound to specific security association.
Please note the security policies can be loaded into kernel
independently
on IKE daemon, so you are guarded even if daemon does not start.
> The issue is that IPSec is protecting a GRE tunnel and if IPSec fails
> for some reason, GRE will be happy to work without it; tunnelling
> everything in the clear. I was just hoping to put some kind of fail
> safe in place so if IPSec stopped working or failed to start,
> unencrypted traffic wouldn't be transmitted.
>
I see, another independent meassure. Unfortunatelly you are out of luck
in case of netfilter on egress traffic.
-- Petr
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Reject non-ipsec traffic
2011-07-24 22:40 ` Greg Scott
@ 2011-07-25 0:32 ` Jan Engelhardt
0 siblings, 0 replies; 15+ messages in thread
From: Jan Engelhardt @ 2011-07-25 0:32 UTC (permalink / raw)
To: Greg Scott; +Cc: netfilter, Ryan Whelan, Petr Pisar
On Monday 2011-07-25 00:40, Greg Scott wrote:
>But wait a minute - something else has gotta be going on here. The
>original rules had an ACCEPT for UDP and TCP port 500 and then for ESP
>and AH.
Yes, and where was the accept for unencrypted packets that do not
belong to IKE? That's the whole point.
>And then the DROP all rule. When the drop all rule is removed,
>then everything comes through[...]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Reject non-ipsec traffic
2011-07-21 0:09 ` Ryan Whelan
2011-07-21 16:55 ` Petr Pisar
@ 2011-07-25 0:47 ` Jan Engelhardt
1 sibling, 0 replies; 15+ messages in thread
From: Jan Engelhardt @ 2011-07-25 0:47 UTC (permalink / raw)
To: Ryan Whelan; +Cc: netfilter, GregScott, petr.pisar, steven.kath
On Thursday 2011-07-21 02:09, Ryan Whelan wrote:
>>>
>>>So the outbound traffic is being processed by netfilter before getting
>>>wrapped by IPSec?
>>
>> Both before and after.
>
>Is there a way to accomplish this? Maybe a way to only accept a
>non-esp packets if it destined for the ipsec stack; is that possible?
>The only other recourse I can think of is dropping on the receiving
>side any non-esp packets. Thats better than nothing, but I'd like to
>not send anything unencrypted if possible.
And don't strip the Cc list.
You can use -m policy in OUTPUT to check for packets destined to be
xfrmed (output path) or having come out of xfrm (input path), i.e.
-A OUTPUT -m policy --dir out --pol ipsec -j ACCEPT
-A OUTPUT [ike port 500/4500] -j ACCEPT
-A OUTPUT -p esp -j ACCEPT
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-07-25 0:47 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-20 19:20 Reject non-ipsec traffic Ryan Whelan
2011-07-20 19:56 ` Jan Engelhardt
2011-07-20 20:13 ` Ryan Whelan
2011-07-20 20:30 ` Jan Engelhardt
2011-07-20 20:33 ` Ryan Whelan
2011-07-20 20:34 ` Jan Engelhardt
2011-07-21 0:09 ` Ryan Whelan
2011-07-21 16:55 ` Petr Pisar
2011-07-21 17:05 ` Ryan Whelan
2011-07-21 19:01 ` Steven Kath
2011-07-21 19:29 ` Jan Engelhardt
2011-07-22 5:15 ` Petr Pisar
2011-07-24 22:40 ` Greg Scott
2011-07-25 0:32 ` Jan Engelhardt
2011-07-25 0:47 ` Jan Engelhardt
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.