firewall filter on ipsec, how to identify the IPSec intrfce

RouterOS General
1

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

Traffic triggering "wrong" IPSEC policy
IPSec Tagging With Mangle/Prerouting
Configuring Firewall Rules for IPSEC / L2TP VPN - Confused
2

bump…

Anyone? Please!

3

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/t/feature-request-openvpn-ovpn-udp-tunnels/23563/1)
  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.

4

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,

5

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

6

…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,

7

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

8

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,

9

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-ipsec-packet-with-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

10

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,

11

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.

12

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.

13

@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.

14

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

15

@gsloop
Because I’m much more Friendly than Manual :smiley: , 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 :frowning: ), 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,

16

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

17

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

18

@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 :slight_smile:
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 :frowning:
There is a book about IPSec ‘Demystifying the IPsec Puzzle’ by Sheila Frankel.
Stop posting, start reading and follow my advices from previous post :slight_smile:

HTH,

19

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).

20

@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