firewall filter on ipsec, how to identify the IPSec intrfce

gsloop · Wed Feb 08, 2012 5:23 am

Perhaps I'm just dumb, but I'm unclear on how I can identify IPSec traffic [not the tunnel setup traffic, but the actual payload traffic] and filter on it.

Is there some way to identify the interface [i.e. ipsec interface] the traffic is coming from. The data from the tunnel simply appears to come from the WAN interface, and while I can allow in traffic based on the source and destination addresses, that won't prevent spoofing from the WAN etc.

I'd rather something like the following.

/ip firewall filter add chain=forward action=accept src-address-list=somenet in-interface=ipsec1 comment="Accept traffic from the ipsec1 tunnel if the source-ip is in somenet."

But, as I said above, I'm not sure how to identify the traffic that's flowing out of the ipsec tunnel via an interface criteria, or some other method.

I'd really appreciate a push in the right direction. I've tried searching the wiki/forum and google, and I can't find anything that applies to ROS.

I'd guess it has to do with ipsec and policy matching [--pol ipsec], but I've never done this and don't see where I'd configure it on ROS.

TIA!
-Greg

gsloop · Fri Feb 10, 2012 11:06 pm

bump...

Anyone? Please!

gsloop · Wed Feb 15, 2012 7:53 pm

In case someone else has this question:

MikroTik support says that the IPSec traffic is not identifiable in FW rules.

In short, all traffic will appear to come from the WAN [or IF the IPSec tunnel is terminated to] and thus, you can't filter specifically on the IPSec traffic. [IMO, this leaves the connection completely open to spoof attacks.]

Alternatives are
1) OpenVPN [However, MikroTik is not really actively supporting OpenVPN, and won't support OVPN over UDP. So using OpenVPN seems like a non-starter.] (See this "The answer was clear - We will not make new OpenVPN features." http://forum.mikrotik.com/viewtopic.php?f=1&t=26499)
2) SSTP. [Again, there are IMO, downsides. SSTP is TCP over TCP - less than optimal. SSTP isn't nearly as widely supported for interop as OpenVPN IPSec are.]

So, essentially there isn't a great alternative for IPSec - but those are your options.

ditonet · Thu Feb 16, 2012 12:42 am

MikroTik support says that the IPSec traffic is not identifiable in FW rules.

Did you try to mark IPSec connection/packet in 'mangle', then allow/drop in 'filter'?

Regards,

gsloop · Thu Feb 16, 2012 2:45 am

Did you try to mark IPSec connection/packet in 'mangle', then allow/drop in 'filter'?

...and how would you go about identifying that traffic in the mangle rules?

[Perhaps I'm dense, but identifying them in mangle seems to have the same problems as in the filter rules.]

-Greg

ditonet · Thu Feb 16, 2012 6:17 pm

...and how would you go about identifying that traffic in the mangle rules?

Mangle/prerouting for ingress traffic, mangle/postrouting for egress traffic, set src-address and dst-address according to your IPSec policy addresses.

HTH,

gsloop · Thu Feb 16, 2012 7:31 pm

But if I'm selecting traffic based on the source and dest address, how is this better than what I can do in filter?

In short,
[Assume the remote end of the IPSec tunnel is 10.0.1.0/24 and the local is 10.0.2.0/24]

filtering for src-addr=10.0.1.0/24 dest-addr=10.0.2.0/24 only means the packet CLAIMS to be from/to those source and destination addresses. There's no guarantee it actually IS.

If I'm sure it's IPSec traffic - ie, it came from the IPSec interface, then I know it's from the IPSec tunnel and I get the inherent guarantees of security/authenticity that the IPSec tunnel gives, which is MUCH greater than that of the source and destination IP address in a packet.

There's nothing to prevent spoofing of traffic should someone find a way to get traffic to the WAN side of the RB that has a source addy of 10.0.1.0/24 and dest of 10.0.2.0/24. [These examples are private IP ranges and input sanitization will help these cases some. But input sanitization won't help [I don't think] if the networks at either end of the ipsec tunnel are publicly routed ip ranges.]

If I understand what you're saying for the mangle rule, this isn't any different than I already do in the filter rules - but neither will prevent a spoof attack.

If I could select traffic via some method like: "in-interface=ipsec1" then you could be sure the traffic ACTUALLY WAS from the ipsec interface, not that it just matched the source/dest addreses. [i.e. You have some form of traffic authentication inherent in the ipsec tunnel. And if you can verify it came from the ipsec tunnel, you can treat the traffic in a more trusted way than traffic that "claims" or appears to be from the tunnel but you can't really verify did.]

Does that make sense, or am I missing something you're offering?

-Greg

ditonet · Thu Feb 16, 2012 10:08 pm

but I'm unclear on how I can identify IPSec traffic

In case someone else has this question:
MikroTik support says that the IPSec traffic is not identifiable in FW rules.

But if I'm selecting traffic based on the source and dest address, how is this better than what I can do in filter?

If firewall/filter rules with src and dst addresses works, just use it.
There is no 'IPSec interface' because IPSec is a set of protocols, not interface.

[Assume the remote end of the IPSec tunnel is 10.0.1.0/24 and the local is 10.0.2.0/24]
filtering for src-addr=10.0.1.0/24 dest-addr=10.0.2.0/24 only means the packet CLAIMS to be from/to those source and destination addresses. There's no guarantee it actually IS.
If I could select traffic via some method like: "in-interface=ipsec1" then you could be sure the traffic ACTUALLY WAS from the ipsec interface, not that it just matched the source/dest addreses.

If you are affraid that attacker can break IPSec by setting remote subnet to value defined by your IPSec policy, that means you simply don't know how exactly IPSec works.
To be honest, I don't know what do you want to achieve with these settings, sorry.

Regards,

gsloop · Fri Feb 17, 2012 3:14 am

I'm not afraid of anyone breaking IPSec.

So, here's where we are:
1) You receive a packet on the WAN interface.
2) It claims to be from somewhere in 10.0.1.0/24 and destined for somewhere in 10.0.2.0/24.
3) You allow it, because those are addresses that are in the remote network and the local one, and if you don't, all your IPSec traffic will get black-holed.

Right? Do I still have you?

So, what's to distinguish that packet from any other packet arriving at the WAN?
Can you be sure it came from the IPSec tunnel?
Answer: NO, you can't!

There's nothing to prevent anyone from sending [or attempting to send] you a packet with forged source addresses.
[Hopefully routers down-stream from you would filter forged source address packets, but you can't count on it.]
The attacker doesn't have to send it over the IPSec tunnel. Just get it to the WAN interface.

But I have to allow that traffic because it could be IPSec traffic. If I block it, all IPSec tunnel traffic will get killed along with it.
In short, you have to have something like the following.

accept in-interface=wan src-addr=10.0.1.0/24 dst-addr=10.0.2.0/24

So, I'm accepting traffic on the WAN interface that I have to assume is via the IPSec tunnel from the network on the remote end, and destined for the local network at my end. But what's to prevent an attacker from spoofing the source address and sending me the same packet?! I still have to "assume" it's from the IPSec tunnel.

So, while spoof attacks are hard to exploit, I should not have to allow such an attack in the first place.

ROS [like native IPSec/FreeSWAN on Linux] should have a way to filter based on interface.

If you do some looking, you can use --pol ipsec to setup policy handling for IPSec traffic. [All about the iptables policy module]
See: http://twobit.us/blog/2010/11/managing- ... -iptables/

Evidently this is NOT available in ROS, and IMO, should be.

There's one other option that I've seen talked about that might perhaps work. That's marking ESP packets in the mangle rules - in Linux, these marks remain after the packet has been decrypted and those marks can be acted on in the filter rules.

However, I really don't know how that's going to work in ROS world. Figuring out how ROS handles this stuff was why I was asking.

-Greg

ditonet · Fri Feb 17, 2012 11:30 am

So, here's where we are:
1) You receive a packet on the WAN interface.
2) It claims to be from somewhere in 10.0.1.0/24 and destined for somewhere in 10.0.2.0/24.
3) You allow it, because those are addresses that are in the remote network and the local one, and if you don't, all your IPSec traffic will get black-holed.

So, what's to distinguish that packet from any other packet arriving at the WAN?
Can you be sure it came from the IPSec tunnel?
Answer: NO, you can't!

Do you really think that packet with private network address (10.0.1.0/24 in this case) is received on WAN interface???
IMHO you misunderstood what about IPSec policy addresses are, they are not firewall 'allow' rules.
You are not able to receive packet from private network (from other side of IPSec tunnel) until IPSec SAs are established.
Every MikroTik gateway configured by me, have firewall rule which drops packets from private network addresses received on WAN interface and IPSec works perfectly.

If you do some looking, you can use --pol ipsec to setup policy handling for IPSec traffic. [All about the iptables policy module]
See: http://twobit.us/blog/2010/11/managing- ... -iptables/
Evidently this is NOT available in ROS, and IMO, should be.

Everything described in mentioned article IS available in RouterOS, just RTFM.

HTH,

gsloop · Fri Feb 17, 2012 7:12 pm

So, since it's all in the *effing* manual, can you tell me how to do the following...
[Should be easy, since it's in the effing manual, right?]

iptables --append FORWARD \
--match policy \
--dir in \
--pol ipsec \
--mode tunnel \
--tunnel-dst ${PUBLIC_IP} \
--tunnel-src 0.0.0.0/0 \
--in-interface extif \
--source 10.0.2.0/24 \
--out-interface wirif \
--destination 10.0.1.0/24 \
--jump ACCEPT

[As far as I can see, and I've read the effing manual quite carefully, there isn't any way to use the ipsec policy match.]

The [RT]FM manual page on filter is here:
http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter

But I'd be more than glad to be proven wrong.

[Lastly, in the 2.4 kernel IPSec *was* treated as an interface. In 2.6 it's now handled as above.]

-Greg

PS. If you would read, you'll note that I talked about using a private range and the problems associated with it, and that I did do input sanitization, but that those rules would be inadequate if public ranges were being used.

There's nothing to prevent spoofing of traffic should someone find a way to get traffic to the WAN side of the RB that has a source addy of 10.0.1.0/24 and dest of 10.0.2.0/24. [These examples are private IP ranges and input sanitization will help these cases some. But input sanitization won't help [I don't think] if the networks at either end of the ipsec tunnel are publicly routed ip ranges.]

However, I used those addresses as an example - and I felt changing those "examples" in the middle of the thread would be confusing. The point is still the same.

changeip · Fri Feb 17, 2012 7:17 pm

Yes, I would like to not allow 192.168.1.0/24 into my WAN interface unless its thru an IPSec tunnel as well. I dont have a choice what the remote end uses, so I have to allow 192.168.1.0/24 in from WAN?

I believe if anything comes from that IP on the wan it will fail because of the ipsec rules, but still seems a little risky.

ditonet · Fri Feb 17, 2012 8:37 pm

@gsloop

[Should be easy, since it's in the effing manual, right?]

Don't try to be sarcastic. When I'm reading sentences like this, I'm feeling that I'm wasting my time and you are unable to learn new things.
As I wrote earlier you don't know how IPSec works and due to your lack of knowledge you simply mix IPSec tunnel establishing with firewall rules.

For me, EOT.

gsloop · Fri Feb 17, 2012 8:57 pm

For me, EOT.

Fine by me.

What's clear to me, is that you have made a claim this IS possible in the filter rules.

Everything described in mentioned article IS available in RouterOS, just RTFM.

But I don't think this IS possible in MT. If it was, I could find someone talking about it, and showing it's possible.

Instead there's no-one talking about ipsec policy match, and you conveniently skip town just when you'd have to actually deliver the goods on your insult or be shown to simply be wrong.

Throwing around insults like RTFM and expecting me to act as though you're being reasonable is in itself unreasonable.
I've read the manual, and I can't find the policy matching that current Linux versions of iptables use to handle ipsec traffic. It's also not possible to handle it as an interface as older versions used.

So, where things were on my third post are where things still stand.
There's no way I'm aware of to handle ipsec traffic differently than any other forward traffic. Because of that, address spoofing becomes a threat.
[Which was the whole point of the linked article and the rule I posted above.]

Frankly, I think the person who fundamentally misunderstands the issues involved is you.

However, if you'd like to show me how it IS possible, and make me eat crow, I'm more glad to do so. I would just like to see how one does ipsec policy matching in the filter rules. [Or the equivalent.]

-Greg

ditonet · Fri Feb 17, 2012 9:48 pm

@gsloop
Because I'm much more Friendly than Manual

, three last advices:
1. Learn how exactly IPSec works and everything you asking about become clear. IPSec ESP payload (with src and dst adresses) is encrypted and these adresses never hit your WAN interface. Don't worry about forged packet, IPSec gives you security, not firewall rules. I tried to show this in my posts (probably without success

), read them again. There is no need to set firewall 'allow' rules for IPSec traffic.
2. Read these Wiki articles:
http://wiki.mikrotik.com/wiki/Manual:IP/IPsec
http://wiki.mikrotik.com/wiki/Packet_Flow
3. Sniff your IPSec traffic with Wireshark and analyze it. Maybe this will be some kind of proof for you.

Regards,

gsloop · Fri Feb 17, 2012 10:14 pm

Lets use this example

Network on the left -- Network on the right
1.0.1.0/24 -- 1.0.2.0/24

IP Sec tunnels between the two.

Assume the RB's are 1.0.1.1 and 1.0.2.1 on their WAN interfaces. [No NAT]

Assume two clients.
1.0.1.10 on the left
1.0.2.10 on the right.

To allow that traffic, you can't say:
/ip firewall filter forward block any traffic from 1.0.1.10 to 1.0.2.10.
If you do that, all ipsec traffic will get killed.
[Because it appears on the WAN interface with the source IP of the sending station and the destination IP of the station it's destined for.]

There's no way to tell it's from the ipsec tunnel.

Now consider this.

Station with ip 2.1.1.2 sends a packet to the RB on the right side [1.0.2.1] with a destination of 1.0.2.10
It forges the source IP as 1.0.1.10

When that packet arrives at the WAN of the RB [1.0.2.1] it will see a packet with source 1.0.1.10 and a destination of 1.0.2.10.

Now, what happens to that packet? It gets forwarded through just fine.

Ergo: Spoof attacks are not defensible unless you can determine the source of ipsec packets. Without the ability to do so, the fw is open to passing packets with carefully forged source addresses/ports.

-Greg

gsloop · Fri Feb 17, 2012 10:20 pm

Finally, I'm still waiting for you to back up this claim

Everything described in mentioned article IS available in RouterOS, just RTFM.

I'll happily go into the sunset with that information. I'd even be glad to send you $20 just for the trouble. Paypal work?

Show me how to create this filter rule:

iptables --append FORWARD \
--match policy \
--dir in \
--pol ipsec \
--mode tunnel \
--tunnel-dst 1.0.2.1 \
--tunnel-src 0.0.0.0/0 \
--in-interface extif \
--source 1.0.2.0/24 \
--out-interface eth1 \
--destination 1.0.1.0/24 \
--jump ACCEPT

[I've even tailored it to the example just above.]

I think I'm pretty safe with my $20 - though I'd be really glad to give it away. The answer is worth more to me than $20.

-Greg

ditonet · Sat Feb 18, 2012 12:19 am

@gsloop
You can't (or won't) understand that IPSec ESP payload is encrypted and encapsulated.
In your example traffic from 1.0.1.10 to 1.0.2.10 is encrypted and encapsulated,
thus potenial attacker will only see traffic from 1.0.1.1 to 1.0.2.1.
Traffic between clients (1.0.1.10 to 1.0.2.10) is only possible
when IPSec Security Associations between gateways (1.0.1.1 <-> 1.0.2.1) are established.
Establishing IPSec SAs is two phase process with pre-shared key or certificates and strong cryptography,
and is considered as safe

Properly configured IPSec tunnel doesn't need firewall rules.
English is not my native language and I don't know how to explain this better

There is a book about IPSec 'Demystifying the IPsec Puzzle' by Sheila Frankel.
Stop posting, start reading and follow my advices from previous post

HTH,

changeip · Sat Feb 18, 2012 2:35 am

you are basically saying that if traffic arrives from that source on the wan interface, and its not part of the ipsec established tunnel, it will be dropped no matter what, because it doesnt match the ipsec policy... correct? It will be dropped before it even hits the firewall because there is an ipsec policy encompassing that src range. So there is no way to spoof the source, unless they are spoofing well enough to take over that ipsec tunnel (no way).

gsloop · Sat Feb 18, 2012 2:42 am

@ditonet

How do you propose preventing the RB from passing traffic from 1.0.1.10 to 1.0.2.10 that *isn't* from the ipsec tunnel? This is the point you seem to keep missing, intentionally or not, I'm not sure.

We shouldn't legitimately ever see that traffic except from over the encrypted ipsec tunnel, thus blocking it would be a good thing, right?

And before you say, "I'll never see that packet on the RB that isn't from the IPSec tunnel..." realize that's a falicy. You very easily can, and will, if someone spoof's a packet with that source address.

The answer is, you can't, without a rule like I want above.

And if you do get a packet on the WAN with that source address, you'll have to pass it into the privileged LAN network, because if you don't, your IPSec network won't work either.

That's the source of the problem.

[At the risk of this turning into a sandbox fight, you're the one who simply doesn't understand the flow of traffic.]

Perhaps you're hoping that NAT will save you, and perhaps it will. But in a non NAT'ed network, that packet will flow right across the WAN to LAN without ever actually coming from the IPSec network.

So, the result is: Either
1)Accept spoofed packets as though they are from the IPSec tunnel and hope nothing bad comes of it, or
2) Drop the IPSec traffic, because you can't verify that packet came from the ipsec tunnel.

Obviously, if you need your IPSec traffic to pass, you have to allow the spoofed packets. Not a good result, IMO.

---
Let me address another point, that you're obviously confused on:

Traffic between clients (1.0.1.10 to 1.0.2.10) is only possible
when IPSec Security Associations between gateways (1.0.1.1 <-> 1.0.2.1) are established.

If 1.0.1.10 and 1.0.2.10 are publicly routed addresses, than sending traffic from one host to another is just normal traffic. It doesn't have to route via an ipsec tunnel. Unless you're doing NAT, then it's a simple route from one to the other. Since it's simple routing, once the RB [or any firewall for that matter] see's a packet with valid source and destination ip addresses, if there isn't a default drop policy, it will simply route the packet.

Thus, a prudent practice is to drop all traffic you don't explicitly want.

So, again, the policy I want is to drop all traffic from 1.0.1.0/24 to 1.0.2.0/24 unless I can guarantee it passed over the ipsec tunnel. And that's the reason I want that rule above.

And it's extremely frustrating to have you blanket claim that ROS will do everything in that linked article above when you simply REFUSE to show how that rule can be built on ROS. [It's my assertion, it can't. Backed up by offering you [or anyone else for that matter] $20 to provide it.]

Last thing.
Before you go write a bunch more stuff - answer this basic question.
How can you be *sure* you will never see a packet on the right side RB's WAN that is from 1.0.1.10 that did NOT come over the ipsec tunnel?

If you can't give a totally bullet-proof answer to that, then solve that problem first. The rest follows from that. If you don't understand it, then don't bother with anything else.

-Greg

changeip · Sat Feb 18, 2012 9:13 am

you didnt understand / read my post correctly. I agree you cannot identify by interface, and i wish we could because I have use for it as well. However, see below:

If ANY packet comes from 192.168.117.x on any interface it will be forced to be decrypted FIRST before the firewall even hits. If that spoofed packet is not IPsec, it will be DROPPED before it even gets to the firewall. Period.

Although, you must have REQUIRE on the policy otherwise it might slip thru...

ditonet · Sun Feb 19, 2012 5:36 am

@gsloop
I've treated your example in pure theoretical way, because I've tried to explain you how IPSec works.
OK, it was my mistake which finally turns against me.
I must ask you some basic, but important question :
Are addresses provided by you (1.0.1.0/24, 1.0.2.0/24) in your 'real-life' example:
1. public, routable
2. public only
And how this information affects your IPSec example in general?
My answers about your 'real-life' IPSec example are simple:
case 1: wrong assumptions (IPSec have nothing to do, due to simple routing)
case 2: example is incomplete (no information how to connect these subnets via IPSec tunnel)
The result of theoretical question is theoretical answer.

The point you seem to still keep missing in your consideration is that you think, that packet which is part of IPSec tunnel is treated by gateway the same way as packet incoming to WAN interface. No, is not because is encrypted and encapsulated. That's all.

otys · Sun Feb 19, 2012 10:22 am

Use GRE over IPSEC if you want vpn to be presented as interface. It is simple and works.

Dan

gsloop · Mon Feb 20, 2012 7:46 am

@ditonet:
First: I'm not sure how ROS impliments IPSec, so perhaps using "required" as part of the policy will sort-of solve this.
It's something I'll look at.

However, that doesn't resolve the proclamation that "Everything in that article is possible in ROS."
It just isn't possible - at least not in any way I've seen.

Also, forcing "required" [provided it works as you think it does] will work, but only if none of that remote traffic needs to travel outside of the tunnel. [I'm not sure I can think of a practical way, or reason for that, but still true.]

So, as said above, I'll investigate and see what I can determine about how ROS handles that. It's worth a look in any case, since there appears to be no way to do it otherwise. [And the granularity of even this solution is horrible IMO - what if one wants to make more nuanced filter decisions?]

As far as taking this further... I've burned quite a lot of time on it, and I think the general points are made.
1) ROS doesn't do what Linux does in handling ipsec policy matching, which has wide applications - and I'd like to have it.
2) There may be a few alternative ways to resolve the issue.
3) Maris has claimed in email to me, that MkRtk is going to extend the IPSec implementation to flesh out some of these things in the future.
4) I have multiple implementations, and the details at each are different. I'm not terribly interested in a specific implementation issue, I'm more interested in the theory and understanding what's possible and what isn't. Then I can make particular/specific implementation decisions for a specific install.

So, I think unless there's more detail to add to the above, this has run it's course. I think I'm pretty clear what ROS can do and what it can't, and what the risks are. I'm not super happy with the result, but it's probably livable.

I'll do some testing and try a few more things as I have time.

---
@otys.

Hmmm... Interesting!? I'm not sure that resolves all of my issues, but let me ponder it. Thanks for the pointer though!

---
-Greg

ditonet · Mon Feb 20, 2012 1:52 pm

However, that doesn't resolve the proclamation that "Everything in that article is possible in ROS."
It just isn't possible - at least not in any way I've seen.

Ok, first rules:

iptables --table filter --append INPUT \
  --in-interface extif                 \
  --proto udp                          \
  --destination ${PUBLIC_IP}           \
  --dport 500                          \
  --source  0.0.0.0/                   \
  --sport 500                          \
  --jump ACCEPT
 
iptables --table filter --append INPUT \
  --in-interface extif                 \
  --proto udp                          \
  --destination ${PUBLIC_IP}           \
  --dport 4500                         \
  --source  0.0.0.0/0                  \
  --sport 4500                         \
  --jump ACCEPT
 
iptables --table filter --append OUTPUT \
  --out-interface extif                 \
  --proto udp                           \
  --destination 0.0.0.0/0               \
  --dport 500                           \
  --source ${PUBLIC_IP}                 \
  --sport 500                           \
  --jump ACCEPT
 
iptables --table filter --append OUTPUT \
  --out-interface extif                 \
  --proto udp                           \
  --destination 0.0.0.0/0               \
  --dport 4500                          \
  --source ${PUBLIC_IP}                 \
  --sport 4500                          \
  --jump ACCEPT
}

They simply allow IKE and IPSEC-NAT-T, info how to set these rules is in Wiki/manual:
http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter

/ip firewall filter
add action=accept chain=input comment=IKE&NAT-T disabled=no dst-port=500,4500 protocol=udp
add action=accept chain=output comment=IKE&NAT-T disabled=no dst-port=500,4500 protocol=udp

iptables -A FORWARD         \
  --in-interface extif      \
  --source 10.0.2.0/24      \
  --out-interface wirif     \
  --destination 10.0.1.0/24 \
  --jump ACCEPT
 
iptables -A FORWARD         \
  --in-interface wirif      \
  --source 10.0.1.0/24      \
  --out-interface extif     \
  --destination 10.0.2.0/24 \
  --jump ACCEPT

I've pointed you in my post to : http://wiki.mikrotik.com/wiki/Manual:IP/IPsec
This feature is called in ROS 'NAT bypass' and is described in this article.

The last and probably most confusing is:

iptables --append FORWARD    \
  --match policy             \
  --dir in                   \
  --pol ipsec                \
  --mode tunnel              \
  --tunnel-dst ${PUBLIC_IP}  \
  --tunnel-src 0.0.0.0/0     \
  --in-interface extif       \
  --source 10.0.2.0/24       \
  --out-interface wirif      \
  --destination 10.0.1.0/24  \
  --jump ACCEPT
 
iptables --append FORWARD    \
  --match policy             \
  --dir out                  \
  --pol ipsec                \
  --mode tunnel              \
  --tunnel-dst 0.0.0.0/0     \
  --tunnel-src ${PUBLIC_IP}  \
  --in-interface wirif       \
  --source 10.0.1.0/24       \
  --out-interface extif      \
  --destination 10.0.2.0/24  \
  --jump ACCEPT

In ROS IPSec tunnel traffic is allowed by default, so there is no need for these rules, especially '--match policy'.
ROS IPSec implementation 'is as is' and works this way, other manufacturers also allows IPSec trafic by default.
All necesery steps to set-up IPSec tunnel are described in the same article as 'NAT Bypass', and this article doesn't say that rule like this is necessary.

mrz · Mon Feb 20, 2012 2:18 pm

Those rules would be necessary if you want to accept that ipsec traffic and drop the rest (non encrypted) traffic.

ditonet · Mon Feb 20, 2012 2:37 pm

@mrz

drop the rest (non encrypted) traffic

Did you mean non encrypted traffic from '10.0.2.0/24' and '10.0.1.0/24' subnets or the whole traffic incoming on WAN interface???

Edit:
In mentioned article http://twobit.us/blog/2010/11/managing- ... -iptables/ (but not in my post), first rules are:

iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

But ROS IPSec works even without these 'accept' rules:

iptables --append FORWARD    \
  --match policy             \
  --dir in                   \
  --pol ipsec                \
  --mode tunnel              \
  --tunnel-dst ${PUBLIC_IP}  \
  --tunnel-src 0.0.0.0/0     \
  --in-interface extif       \
  --source 10.0.2.0/24       \
  --out-interface wirif      \
  --destination 10.0.1.0/24  \
  --jump ACCEPT

iptables --append FORWARD    \
  --match policy             \
  --dir out                  \
  --pol ipsec                \
  --mode tunnel              \
  --tunnel-dst 0.0.0.0/0     \
  --tunnel-src ${PUBLIC_IP}  \
  --in-interface wirif       \
  --source 10.0.1.0/24       \
  --out-interface extif      \
  --destination 10.0.2.0/24  \
  --jump ACCEPT

Regards,

gsloop · Mon Feb 20, 2012 8:32 pm

I'm buried today...but I need to review the posts. I'm most interested in @mrz's post, since that appears to support my initial position - which is:
Without ipsec policy match, then spoofed traffic will very potentially flow through the filter-rules.

[More complete/expansive explanation:
Without being able to determine which traffic came through the ipsec tunnel [which ipsec policy matching does] you can't make any decisions about which traffic you see in the filter rules to drop or allow. ANY packet which has the apparent correct source and destination addresses will look the same, regardless of it's origin - ipsec tunnel or just the WAN interface.

You either drop all, or allow all. If you allow all, ipsec traffic will flow, but so will spoofed traffic. If you deny all, you will be protected against a spoof attack, but then all your ipsec traffic will get dropped or rejected - which obviously is a no-go.]

-Again, once I have some time to reply, I'll try to do so more fully.

-Greg

PS.
@mrz: Would you be so kind as to clarify your post? I think you are agreeing with the need for an ipsec policy match to prevent spoofed traffic, but I don't want to place words in your mouth, or to extrapolate this to something it shouldn't.

ditonet · Tue Feb 21, 2012 12:15 am

Without ipsec policy match, then spoofed traffic will very potentially flow through the filter-rules

Without IPSec policy match, IPSec tunnel IS NOT established, thus there IS NO IPSec traffic flow.
In site-to-site IPSec VPN also gateways addresses are strictly defined in IPSec policies, for roadwarriors any (0.0.0.0/0) address is allowed.
Even if remote subnets addresses and gateways addresses match, also initial key exchange must occur (or certificate checking).
This is done using strong cryptography. After succesful key exchange and IPSec policy match, encrypted tunnel is established.
All traffic between remote subnets is encrypted and encapsulated, thus NOT visible to potential attacker.
Is not possible to read subnets addresses from encrypted packets.
Even if you send spoofed packet, with proper subnet src and dst addresses to gateway's public interface,
it'll be treated by gateway like every other packet on public/WAN interface (according to your firewall rules in 'input' chain), but not part of IPSec traffic.
IPSec traffic is decrypted by gateway itself, then flows to firewall's 'forward' chain.
http://wiki.mikrotik.com/wiki/Packet_Fl ... decryption

HTH,

gsloop · Tue Feb 21, 2012 7:27 am

Even if you send spoofed packet, with proper subnet src and dst addresses to gateway's public interface,
it'll be treated by gateway like every other packet on public/WAN interface (according to your firewall rules in 'input' chain), but not part of IPSec traffic.

Exactly! You're exactly right, but you're still missing the picture.

I am NOT concerned about someone penetrating the IPSec tunnel.
REPEAT. I have no concerns about someone "hacking" the IPSec tunnel. [Or at least those concerns are not part of this discussion.]

However. when a packet hits the WAN interface, you have to decide what to do with it.

And there's no way to handle an IPSec packet differently than any other packet, given identical source and destination addresses.
REPEAT: There's no way to handle an IPSec packet differently than any other packet, given identical source and destination addresses.

In ROS, at the WAN interface where input/forward/output rules occur, all IPSec packets look just like any other packet.
At that point, they're not IPSec packets, they're just packets. All packets, IPSec or just on the WAN interface all flow into the same bucket - and there's no way to sort them out, and know which actually came over the VPN tunnel and which didn't. [Note, this is how it is in ROS, not in Linux.]

See this description

ipsec -- WAN |FW| LAN
general internet -- WAN |FW| LAN

I can deliver a packet to the WAN interface [ROS's input/forward/output chains] via two methods here.
1) IPSec
2) Regular packet, not encrypted etc.

However, by the time I see that packet in the forward interface, it's just a WAN packet. It's real method of delivery (IPSec or Regular WAN traffic) can't be determined. Right?

It just says Src-addr=1.0.1.10 Dest-Addr=1.0.2.10 [and some port, and data payload etc.]

So, I can say,
1) either drop [src-addr=1.0.1.10 dst-addr=1.0.2.10] traffic [which means I kill all ipsec traffic.]
2) Allow [*all*] [scr-addr=1.0.1.10 dst-addr=1.0.2.10] traffic. [Obviously the only real choice.]

So, lets assume we do #2.
But if someone sends a packet to my WAN interface with a source address of 1.0.1.10 and it arrives outside the IPSec tunnel, my forward rules will simply say - allow all traffic from 1.0.1.10 to 1.0.2.10. Thus that packet flows into my network.

I shouldn't allow packets into my network, that I don't explicitly want.
I want IPSec traffic, I don't want stuff that isn't.

Said another way, in the linked article.
http://twobit.us/blog/2010/11/managing- ... -iptables/

These rules look pretty tight right? We’ve limited the the networks that can communicate and the interfaces on which the traffic should originate. We can do better though.

I’m particularly wary of the interface on the router that’s connected to the internet. The iptables rules above will allow the traffic we want to allow but it doesn’t require that the traffic from the 10.0.2.0/24 network arrive over the VPN! Theoretically an attacker that isn’t on the VPN could spoof traffic with the VPN IP and exchange packets with the protected 10.0.1.0/24 network. This is bad.

So, the issue isn't compromising the VPN tunnel. The problem is the fact that the remote VPN ip/network address [or range] is "privileged" in our forward rules. We want to prevent anyone from exercising that privileged state unless we can be sure they're actually, verified members of that privileged network.

Since the IPSec tunnel is pretty secure itself, using the fact that the traffic came from the IPSec tunnel as a verification mechanism works really well. It would be really unlikely that we'd get traffic over the VPN tunnel that wasn't really from the tunnel. [If it is, then we have a *very* serious problem with the tunnel itself.]

But instead of actually using the fact that it came over the tunnel, which we can't do in ROS, we have to use the src-address as the "verification." However, as we all know, the src-addr IS NOT SECURE, AND SHOULD NEVER BE USED AS A DEFACTO AUTHENTICATION METHOD.

Repeat: We can't use the fact that the packet came over the VPN tunnel to "authenticate" it in ROS. We only have one "authentication" method available in ROS's forward rules - using the src-addr and dst-addr.

But we know that we can NOT trust the src-address of a packet arriving at the WAN interface. We probably could, provided we knew it was over the IPSec tunnel, but not at the WAN interface.

But in this case, we have no choice. We have to allow, in the forward rules, packets from 1.0.1.10 to 1.0.2.10, regardless of actual transport - ipsec or just arriving on the WAN interface.

As said above. This is bad.

-Greg

PS. Again, I have not digested much of the thread since Friday.

There are claims that a "level=required" policy would drop all traffic from from the privileged network, if it didn't originate from the ipsec tunnel. But it won't.

While I'd agree it won't be accepted over the ipsec tunnel itself, there's nothing that this will do to prevent a packet claiming to be from the same address as the [/ip ipsec policy src-address] arriving *outside* the IPSec tunnel into the WAN interface flowing through the forward rules.

So, this doesn't improve the situation at all.

Once again, in ROS while making routing/forwarding decisions in the input/forward/output chains, you have to use the src-address/dst-addr of the packet as a substitute for the strong authentication one would have if they could KNOW the packet came from the IPSec tunnel.

---
I'm not sure running it over a GRE tunnel improves this problem, but I'm planning on investigating.

gsloop · Tue Feb 21, 2012 8:02 am

Just as a follow-up and a demonstration.
In your forward rules - right at the top.

Place a rule as follows
/ip firewall filter chain=forward action=drop src-address=a.a.a.a/m dst-address=b.b.b.b/m

Where a.a.a.a/m is the same as /ip ipsec policy dst-address and b.b.b.b/m is the same as /ip ipsec policy src-address

---
What you'll find is that all your IPSec traffic gets dropped.

So, if you truly DID sanitize your WAN for private addresses [i.e. drop all RFC1918 traffic at the WAN], you'll also be dropping all IPSec traffic on networks that use private addresses.

So, clearly you ARE NOT sanitizing your WAN interfaces for all private network addresses OR your networks at either end of your ipsec tunnels aren't private address schemes. [Or perhaps there's a rule allowing what you assume is ONLY ipsec traffic from a.a.a.a/m to b.b.b.b/m - but as we discussed above, you can't be sure that traffic really IS from the ipsec tunnel.]

[If you do NAT, it's _probably_ less of a threat and if you use RFC1918 blocks, it's _probably_ even less of an issue.]
However, I'm not so hip on relying on NAT and private RFC1918 block addressing to save my sorry a$$.

But what this also demonstrates is that if your WAN and LAN interfaces use publicily routed IP's, spoofing the IP address block of the remote end of an IPSec tunnel is a real-world threat.

[A different discussion is exploit-ability of that spoofing. Perhaps spoofing doesn't allow you to do anything useful - your packets go through but don't net the attacker anything. But I'd rather just block them than hope they don't get them anything. {It's like saying "I don't lock my door, because I have a guy who looks in everyone's bags really carefully, so I don't worry about anyone stealing stuff." Me? Well, I think it's just a lot easier locking the door.}]

Especially as we move to IPv6 which should kill NAT for good, one needs to start thinking of truly publicly addressable, routable networks and get away from relying on NAT and private blocks to hide behind.

They are crutches and they don't do us any favors, IMO. But we've gotten used to assuming they are there and, IMO, lazy in the process.

-Greg

mrz · Tue Feb 21, 2012 9:56 am

[More complete/expansive explanation:
Without being able to determine which traffic came through the ipsec tunnel [which ipsec policy matching does] you can't make any decisions about which traffic you see in the filter rules to drop or allow. ANY packet which has the apparent correct source and destination addresses will look the same, regardless of it's origin - ipsec tunnel or just the WAN interface.

You either drop all, or allow all. If you allow all, ipsec traffic will flow, but so will spoofed traffic. If you deny all, you will be protected against a spoof attack, but then all your ipsec traffic will get dropped or rejected - which obviously is a no-go.]

Yes, that is exactly what is happening.

You can even see example in packetflow diagram, that currently it is not possible to determine whether packets came from ipsec tunnel or directly without encryption because in forward chain you already see decrypted packets
http://wiki.mikrotik.com/wiki/Manual:Pa ... decryption

gsloop · Tue Feb 21, 2012 6:23 pm

@mrz

So, it does pass the input chain before getting decrypted. Would it be possible to:
1) set marks on the ESP payload packets in mangle rules.
2) those marks will be maintained and not lost in decryption
3) that you could act on those marks in the forward chain after decryption?

This is the only "good" work-around that seems plausible. My question is: will this work in ROS?

-Greg

ditonet · Wed Feb 22, 2012 1:09 am

@gsloop
OK, I understand your explanation and examples, and agree that in 'forward' chain is not possible to determine the origin of packet.
As you wrote earlier IPSec decrypted packet should be marked in some way,
a flag or something similar, thus it will be very easy to drop unmarked packets in 'forward' chain.
But really nice feature like this must be considered by RouterOS developers.
Anyway, thanks for a stormy discussion

Regards,

changeip · Wed Feb 22, 2012 5:25 am

trust me, if you have an ipsec policy in place that traffic will either need to be successfully decrypted, or dropped. it will be dropped before it even hits the forward chain in the firewall if it didnt come thru the tunnel.

gsloop · Wed Feb 22, 2012 8:08 am

trust me, if you have an ipsec policy in place that traffic will either need to be successfully decrypted, or dropped. it will be dropped before it even hits the forward chain in the firewall if it didnt come thru the tunnel.

We're talking about traffic that arrives at the WAN interface vs traffic that arrives via IPSec.

I don't know how many times I've said that I'm not [at least not in this thread] worrying about someone penetrating the ipsec tunnel.

Here's the crux of the issue

So, the issue isn't compromising the VPN tunnel. The problem is the fact that the remote VPN ip/network address [or range] is "privileged" in our forward rules. We want to prevent anyone from exercising that privileged state unless we can be sure they're actually, verified members of that privileged network.

Since you can't distinguish IPSec traffic from regular WAN traffic, you have to pass traffic that has a src-address of the ip/network at the remote end of the ipsec tunnel, and the dst-address of the local network.

But if a packet with those same source and destination addresses can be passed to the WAN interface of your ROS device - even if it's not inside the ipsec tunnel, your ROS device will pass it into your privileged LAN - EVEN THOUGH IT DIDN'T COME FROM THE IPSEC TUNNEL.

The reason is there's no way to determine that traffic you're forwarding is from an IPSec tunnel or just delivered to the WAN interface.

Really, if you don't understand that, go re-read my posts. I'm totally unsure how to make it any more clear or explicit.
And it's not me saying this now, it is also ROS support.

Packet spoofing is a real threat when using IPSec when you can't use ipsec policy matching [or its equivalent] in the forward rules.

As of now, there's no cure for that illness.

-Greg

changeip · Wed Feb 22, 2012 8:40 am

your still not listening / reading:

But if a packet with those same source and destination addresses can be passed to the WAN interface of your ROS device - even if it's not inside the ipsec tunnel, your ROS device will pass it into your privileged LAN - EVEN THOUGH IT DIDN'T COME FROM THE IPSEC TUNNEL.

No, you should NEVER see traffic from that source anywhere in the routeros firewall UNLESS it has been processed by ipsec and actually came thru the tunnel. If its not part of the tunnel, meaning spoofed, arrived by magic, whatever - it will not be processed / routed / accepted.

Test it, place a source policy for 8.8.8.8/32 and then try some dns queries against that ip ... the replied should not come back thru if you have a policy covering that source range. place a mangle rule in the prerouting chain and you most likely will not see it trigger.

if you do, change your ipsec policy to 'require' and try again.

ditonet · Wed Feb 22, 2012 10:50 am

@gsloop & changeip
In Wiki Packet Flow manual, there is automated process 'Routing Decision' with description:

router goes through the route in order to find a match to destination IP address of packet. When match is found - packet will be send out via corresponding port or to the router itself . In case of no match - packet will be discarded.

When spoofed packet hits WAN interface, firstly is checked against 'prerouting' chain.
If packet doesn't match DST-NAT rule, flows to 'Routing Decision' process.
According to Wiki description, when route to subnet is found, spoofed packet (with dst address to subnet) flows through 'forward' chain, not 'input'.
That means gsloop is right, also mrz's posts suggests the same.
I'm really interested about this, and it should be definitely explained by MT staff.

Regards,

gsloop · Thu Feb 23, 2012 8:12 am

@ditonet
Thanks!

[And nice name, BTW!]

---
Obviously NAT and private RFC1918 blocks change this situation some...

But as said above, I think relying on these is less than optimal, and a crutch and will likely be a serious problem in IPv6. [Since that should drive a much needed stake through the heart of NAT and private net-blocks (rfc1918) too!]

I'd just like to get on with IPv6, frankly. It's going to be painful and lots of stuff is going to break, but lets just do it. We've all had long enough to "think" and tinker with it - it's like switching from English to Metric/SI units. We fools in the USA put it off for too long, and we still stuck with that stinking system! [And we didn't even invent the freeking thing - the English did, and even they abandoned it!]

Cheers!

-Greg[ory]

Thu Feb 23, 2012 1:21 pm

Internet Protocol security (IPSec) is a protocol, not a service, that provides encryption, integrity, and authentication services for IP-based network traffic

IPsec is a service as well. Read RFC4301 (http://tools.ietf.org/html/rfc4301). From that RFC:

5.2. Processing Inbound IP Traffic (unprotected-to-protected)
....
IPsec MUST perform the following steps:
....
3b. If the packet is not addressed to the device or is addressed to
this device and is not AH or ESP, look up the packet header in
the (appropriate) SPD-I cache. If there is a match and the
packet is to be discarded or bypassed, do so. If there is no
cache match, look up the packet in the corresponding SPD-I and
create a cache entry as appropriate. (No SAs are created in
response to receipt of a packet that requires IPsec protection;
only BYPASS or DISCARD cache entries can be created this way.) If
there is no match, discard the traffic. This is an auditable
event. The audit log entry for this event SHOULD include the
current date/time, SPI if available, IPsec protocol if available,
source and destination of the packet, and any other selector
values of the packet that are available.

changeip is right, a packet, that matches your IPsec policy but arrives to your device unprotected must be discarded before it ever reaches your firewall chains. I'm not sure if ROS does it this way, but if it doesn't then it is a serious violation of the standards that exposes a major security problem and must be fixed ASAP.

mrz · Thu Feb 23, 2012 2:34 pm

RouterOS does exactly as it is written in RFC and what changeip said. If there is no match packets are discarded.

rmichael · Fri Feb 24, 2012 12:16 am

You can use bridge filter to filter out private IP traffic comming through WAN. Bridge filter will not touch the encapsulated IPsec payload with the same private IP.

Of course the filter is only necessary when the IPSec tunnel is down since packets will be automatically dropped otherwise.

emuell · Fri Dec 07, 2012 5:30 pm

Sorry to bring this up again, but it's a interesting discussion and i am faced with the same question.

RouterOS does exactly as it is written in RFC and what changeip said. If there is no match packets are discarded.

in my case the tunnel is not always up. will the packages also discarded when the tunnel is down ?

in the wiki i found the following method to identity ipsec-traffic and block the rest: http://wiki.mikrotik.com/wiki/IPSEC_bet ... ed_traffic

does that help or not?

Thx!

emuell · Fri Dec 07, 2012 5:31 pm

Sorry to bring this up again, but it's a interesting discussion and i am faced with the same question.

RouterOS does exactly as it is written in RFC and what changeip said. If there is no match packets are discarded.

in my case the tunnel is not always up. will the packages also discarded when the tunnel is down ?

in the wiki i found the following method to identity ipsec-traffic and block the rest: http://wiki.mikrotik.com/wiki/IPSEC_bet ... ed_traffic

does that help or not?

Thx!

efaden · Sun Jul 07, 2013 9:57 pm

Anyone ever figure this out? All my IPSec traffic is getting dropped by by frewalls default drop policy for the input chain.

MarcusW · Thu Sep 26, 2013 2:10 am

Is there any solution for this yet? The information in the wiki that says you can match ipsec traffic in the prerouting chain seems to be outdated, at least it doesn't work.

MK; have you changed something around this in v6? It also seems I don't need the allow rules in input chain for ipsec any more.. Should it be like that?

mrz · Thu Sep 26, 2013 10:46 am

This is not solution for Ipsec/L2TP setups, works only with ipsec in tunnel mode.
See this wiki article if anyone is interested:
http://wiki.mikrotik.com/wiki/IPSEC_bet ... ed_traffic

efaden · Thu Sep 26, 2013 3:28 pm

This is not solution for Ipsec/L2TP setups, works only with ipsec in tunnel mode.
See this wiki article if anyone is interested:
http://wiki.mikrotik.com/wiki/IPSEC_bet ... ed_traffic

Mrz: See http://forum.mikrotik.com/viewtopic.php?f=2&t=74500

I tried to use it for IPSec tunnel mode packets... it didn't match anything. In version 6.1 at least.

mrz · Thu Sep 26, 2013 3:41 pm

I just copy pasted the same rules from wiki.. Works like a charm.
Probably you have misconfiguration somewhere. Contact support with attached supout files.

efaden · Thu Sep 26, 2013 3:47 pm

I just copy pasted the same rules from wiki.. Works like a charm.
Probably you have misconfiguration somewhere. Contact support with attached supout files.

I gave up on it a while ago... I'll have to give it another test. Thanks

MarcusW · Sat Sep 28, 2013 6:17 pm

I just copy pasted the same rules from wiki.. Works like a charm.
Probably you have misconfiguration somewhere. Contact support with attached supout files.
I gave up on it a while ago... I'll have to give it another test. Thanks

Well, I have checked and rechecked my configuration and it still fails to hit that mangle rule. I use tunnel-mode... I have asked the same question to the support department and they say it works. I can't find any reason what it's not working for me. This only works in tunnel-mode, or are supposed to work there at least, so if you're using transport mode there is no possibility to match it. Really bad!

You can put your wan interface in a bridge though and then use bridge filter rules to filter away incoming unencrypted traffic because there you see the traffic before it's decrypted and then you know it's not supposed to be there. I still think that this is a weakness in MT-routers though and I would like to have IPSEC traffic like an interface AND most important that they fix OpenVPN!! They are stupid when they leave that out!

CPromper · Fri Mar 18, 2016 11:33 am

Hello to all,

maybe I have a solution for this (checked with ROS v6.34.3).

Example:

MT1: 172.29.0.0/24
MT2: 192.168.0.0/24

In forward chain:

chain=forward src-address=172.29.0.0/24 dst-address=192.168.0.0/24 in-interface=WAN out-interface=LAN

When you add ipsec-policy=in,ipsec to your forward chain, then only encrypted traffic will be passed to the LAN.

I've checked it with 2 Mikrotiks, when I remove the option ipsec-policy I can ping into the LAN, with this option the packets will be dropped (dropped=default policy of course).

Kind regards

mrz · Tue Mar 22, 2016 10:31 am

http://wiki.mikrotik.com/wiki/Manual:IP ... ed_Traffic

dfxer · Thu Jul 20, 2017 2:40 pm

Hi!

Testing IKEv2.

ROS 6.39.2.

Router ip: 1.1.1.1
Client ip: 2.2.2.2 (for this example, dynamic and unknown in real)
Pool for clients: 192.168.7.20-192.168.7.50

/ip ipsec policy
set 0 dst-address=192.168.7.0/24 src-address=0.0.0.0/0

/ip firewall filter
.....
add action=accept chain=input dst-port=500,4500 protocol=udp
add action=drop chain=input

After establishing connection policy looks like this:

0 T * group=default src-address=0.0.0.0/0 dst-address=192.168.7.0/24 protocol=all proposal=default template=yes

 1  DA  src-address=0.0.0.0/0 src-port=any dst-address=192.168.7.20/32 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=yes
       sa-src-address=1.1.1.1 sa-dst-address=2.2.2.2 proposal=default priority=2 ph2-count=1

and there is no access behind the router.

Trying to add filter rule:

/ip firewall filter add chain=input action=accept ipsec-policy=in,ipsec place-before=<last deny rule>

nothing changed. /ip firewall filter print stats shows 0 bytes/packets for that rule.
Trying different rule:

/ip firewall filter add chain=input action=accept protocol=ipsec-esp place-before=<last deny rule>

and all works.

Why ipsec-policy=in,ipsec does not catch traffic in my configuration? May be I need to tune policy in some way?

Thank you in advance.

Who is online