Hi, I have a situation where I've got two CCRs with a GRE tunnel between them.

The problem is, I need to secure all random traffic which goes over that GRE tunnel with IPSec.

In the settings where you define policy, you are only allowed to match packets based on their src/dst-address information, not on interface.

Am I missing something?

If all you need to do is encrypt the GRE tunnel, then you just create your policy based on the source and destination IPs of the GRE endpoints. This is called IPSec transport mode. Essentially it encrypts the communication between the two routers, which in turn encrypts the information in the tunnel.

If you need to encrypt each individual stream of traffic going over the tunnel individually (ie: stream 1 to client 1 needs encryption policy 1, and stream 2 to client 2 needs encryption policy 2), then you've got a little more setup involved and would have to define source/destination pairs in your policies.

Thank you for your reply. Yeah, I just need to secure the tunnel itself. In fact I tried to specify tunnel endpoints in src-address and dst-address in policy and set tunnel=yes (afaik transport mode only secures traffic originating and destined to the peers themselves, not other hosts) but it got me nowhere (transit traffic going over the tunnel was still sent as clear text -- i checked with wireshark). I suppose that's because the packets were supposed to be matched by their src/dst addresses and they were not those of the tunnel's endpoints but rather some random hosts in the network.

Thank you for your reply. Yeah, I just need to secure the tunnel itself. In fact I tried to specify tunnel endpoints in src-address and dst-address in policy and set tunnel=yes (afaik transport mode only secures traffic originating and destined to the peers themselves, not other hosts) but it got me nowhere (transit traffic going over the tunnel was still sent as clear text -- i checked with wireshark). I suppose that's because the packets were supposed to be matched by their src/dst addresses and they were not those of the tunnel's endpoints but rather some random hosts in the network.

You're very close to the right track. Tunnel mode actually creates an IPSec tunnel for two subnets. If you had a traditional site-to-site with 2 subnets, you could get away with a tunnel.

You do want to use transport mode here (so uncheck the tunnel mode option) and use ESP for your protocol. This will encrypt the entire packet flow from end to end. AH just assures you're communicating with the party you intend on, it does not provide data encryption.

[admin@crs] /ip ipsec policy> set 1 tunnel=no
failure: transport mode policy must match sa endpoints

eh, still no luck. It seems it wants me to make src and sa-src and dst and sa-dst addresses the same. That means that all traffic between the two routers will be matched, not just the GRE tunnel. :-/

Not knowing exactly what you are doing with the GRE tunnel, could you assign an IP to each end of the tunnel and use IPSec to encrypt that. Then use those IPs for any of your traffic distribution?

It's basically like this:

Two routers:

R1 (HQ) <---------GRE----------> R2 (Remote branch)

R1 WAN IP: 81.29.10.2
R1 GRE IP: 172.17.1.1/30

R2 WAN IP: 77.232.60.34
R2 GRE IP: 172.17.1.2/30
LAN at remote branch: 10.222.0.0/16

Many different hosts located in different networks are routed through the HQ router and use the GRE tunnel to access the remote network 10.222.0.0/16 at the remote branch.

Currently the GRE tunnel is not encrypted, which is bad.
I am trying to secure the GRE and the GRE only (not just any traffic between R1 and R2)

Right now this config works:
HQ:

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 lifetime=1h
/ip ipsec peer
add address=77.232.60.34/32 comment=HQ enc-algorithm=aes-128 local-address=81.29.10.2 nat-traversal=no secret=megasecret
/ip ipsec policy
add comment=Branch dst-address=77.232.60.34/32 sa-dst-address=77.232.60.34 sa-src-address=81.29.10.2 src-address=81.29.10.2/32

Branch:

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 lifetime=1h
/ip ipsec peer
add address=81.29.10.2/32 comment=HQ enc-algorithm=aes-128 local-address=77.232.60.34 nat-traversal=no secret=megasecret
/ip ipsec policy
add comment=HQ dst-address=81.29.10.2/32 sa-dst-address=81.29.10.2 sa-src-address=77.232.60.34 src-address=77.232.60.34/32

But it secures ALL traffic between R1 and R2, not just the GRE tunnel.

RouterOS will not let you use transport mode if sa-src/src and/or sa-dst/dst addresses do not match in policy, so in order to use transport mode you have to use the same addresses for src and sa-src and dst and sa-dst settings.

Just wait for ROS 6.30...it will have GRE encryption:

*) tunnels - eoip,eoipv6,gre,gre6,ipip,ipipv6,6to4 tunnels have new property - ipsec-secret - for easy setup of ipsec encryption and authentication;

In the IPSEC policy just change the protocol from all to GRE. This will then cause only the encryption of GRE packets leaving all other traffic in the clear.

Out of curiosity what other traffic are you worried about being encrypted by the more open policy?

In the IPSEC policy just change the protocol from all to GRE. This will then cause only the encryption of GRE packets leaving all other traffic in the clear.

Out of curiosity what other traffic are you worried about being encrypted by the more open policy?

Wah, I missed that. Thanks, with protocol set to gre it now encrypts only the GRE traffic (however it seems to leak GRE keepalive packets in the clear, at least on one router, hmmm)

I am not worried about other traffic being encrypted, that's just not needed. Most of the "other traffic" is SSH packets and ICMP, no need to waste CPU encrypting that.

Now my SAs are in the perpetual state of "dying" but I think that's just a bug of RouterOS and am not worrying much, since identical configurations on other boxes (differing only in RouterOS version) are producing "mature" SAs.