Gre over IPsec

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

Hi,
I was looking at Glendale Alpha2 and GRE tunnels.
So basically I have three sites with three Glendales: R1, R2 and R3.
A quick hub and spoke architecture R2 is the hub and R1 and R3 the spokes.
There are two situations:
- R1, R2 and R3 connected to the same subnet
- R1, R2 and R3 connected through a router R4(another Glendale)
a)
|-R1
|
|
|-R2
|
|
|-R3

b)
R1
|
|
R4---R2
|
|
R3

I've setup the GRE tunnels with OSPF.
That was easy and it's working nicely in both situations.
The routing table is fine and I have connectivity.
Obviously I want to protect the GRE tunnel with IPsec.
And this does not appear to work.
For the local and remote subnet I have used the local and remote GRE tunnel endpoints, X.X.X.X/32 (basically I have followed pretty much the same steps I use with Cisco routers).
The IPsec interface was the eth0(external interface, like with the newer Cisco IOS).
In situation a) it's working.
In situation b) it's not working.
Looking at the routing table I've noticed a Kernel route to the remote endpoint tunnel, saying that X.X.X.X/32 is directly connected.
And a lot of ARP messages sent from the local external interface to the remote tunnel endpoints.
Of course in situation a) that's not a problem since they are in the same subnet.
But in situation b) that's a problem.
It appears that the Kernel route is causing troubles, and Glendale thinks that the remote endpoint is a local one (the ARP messages).
Actually I can see, depending how I synchronize the commit command, the IKE MM and QM negotiation going fine.
But as soon as that route appears, ARP messages will start to flow.
And the traffic does not follow the normal path.
So I was wondering if this scenario works with Glendale or if I've used a wrong approach.
Thanks,
Adrian

stig · Posted: Fri Mar 14, 2008 2:52 pm Post subject:

Below is a example configuration that I used to set up a ipsec tunnel between 2 routers (running glendale alpha 2) with a GRE tunnel over the ipsec tunnel. This example also has OSPF enabled and I was able to verify that I could pass OSPF multicast packets over the tunnels and use it to discover the networks on both sides. Let me know if this works for you.

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

Hi Stig,
You're a natural superstar! Cool

It's working!
Thanks!
I was trying some net diagrams like this and this.

So using your approach:

HQ:

interfaces {
ethernet eth0 {
address 192.168.50.2/24
duplex auto
hw-id 00:0c:29:8e:ac:e0
speed auto
}
ethernet eth1 {
address 192.168.10.1/24
duplex auto
hw-id 00:0c:29:8e:ac:ea
speed auto
}
loopback lo {
address 9.0.0.1/24
address 10.0.0.1/24
}
tunnel tun0 {
address 7.0.0.1/24
encapsulation gre
local-ip 9.0.0.1
remote-ip 11.0.0.1
ttl 255
}
tunnel tun1 {
address 15.0.0.1/24
encapsulation gre
local-ip 10.0.0.1
remote-ip 12.0.0.1
ttl 255
}
}
protocols {
ospf {
area 0 {
network 192.168.10.0/24
network 7.0.0.0/24
network 15.0.0.0/24
}
log-adjacency-changes {
}
}
static {
route 0.0.0.0/0 {
next-hop 192.168.50.1 {
}
}
}
}
service {
nat {
rule 10 {
outbound-interface eth0
source {
address 192.168.10.0/24
}
type masquerade
}
}
vpn {
ipsec {
copy-tos disable
esp-group foo {
compression disable
lifetime 3600
mode tunnel
pfs enable
proposal 1 {
encryption aes128
hash sha1
}
}
ike-group foo {
aggressive-mode disable
lifetime 28800
proposal 1 {
encryption aes128
hash sha1
}
}
ipsec-interfaces {
interface eth0
}
site-to-site {
peer 192.168.60.2 {
authentication {
mode pre-shared-secret
pre-shared-secret test
}
ike-group foo
local-ip 192.168.50.2
tunnel 1 {
allow-nat-networks disable
allow-public-networks disable
esp-group foo
local-subnet 9.0.0.0/24
remote-subnet 11.0.0.0/24
}
}
peer 192.168.70.2 {
authentication {
mode pre-shared-secret
pre-shared-secret 12345
}
ike-group foo
local-ip 192.168.50.2
tunnel 1 {
allow-nat-networks disable
allow-public-networks disable
esp-group foo
local-subnet 10.0.0.0/24
remote-subnet 12.0.0.0/24
}
}
}
}
}

Branch1:

interfaces {
ethernet eth0 {
address 192.168.60.2/24
duplex auto
hw-id 00:0c:29:54:0b:7e
speed auto
}
ethernet eth1 {
address 192.168.30.1/24
duplex auto
hw-id 00:0c:29:54:0b:88
speed auto
}
loopback lo {
address 11.0.0.1/24
}
tunnel tun0 {
address 7.0.0.2/24
encapsulation gre
local-ip 11.0.0.1
remote-ip 9.0.0.1
ttl 255
}
}
protocols {
ospf {
area 0 {
network 192.168.30.0/24
network 7.0.0.0/24
}
log-adjacency-changes {
}
}
static {
route 0.0.0.0/0 {
next-hop 192.168.60.1 {
}
}
}
}
service {
nat {
rule 10 {
outbound-interface eth0
source {
address 192.168.30.0/24
}
type masquerade
}
vpn {
ipsec {
esp-group foo {
compression disable
lifetime 3600
mode tunnel
pfs enable
proposal 1 {
encryption aes128
hash sha1
}
}
ike-group foo {
aggressive-mode disable
lifetime 28800
proposal 1 {
encryption aes128
hash sha1
}
}
ipsec-interfaces {
interface eth0
}
site-to-site {
peer 192.168.50.2 {
authentication {
mode pre-shared-secret
pre-shared-secret test
}
ike-group foo
local-ip 192.168.60.2
tunnel 1 {
allow-nat-networks disable
allow-public-networks disable
esp-group foo
local-subnet 11.0.0.0/24
remote-subnet 9.0.0.0/24
}
}
}
}
}

Branch2:

interfaces {
ethernet eth0 {
address 192.168.70.2/24
duplex auto
hw-id 00:0c:29:00:f1:67
speed auto
}
ethernet eth1 {
address 192.168.40.1/24
duplex auto
hw-id 00:0c:29:00:f1:71
speed auto
}
loopback lo {
address 12.0.0.1/24
}
tunnel tun0 {
address 15.0.0.2/24
encapsulation gre
local-ip 12.0.0.1
remote-ip 10.0.0.1
ttl 255
}
}
protocols {
ospf {
area 0 {
network 192.168.40.0/24
network 15.0.0.0/24
}
log-adjacency-changes {
}
}
static {
route 0.0.0.0/0 {
next-hop 192.168.70.1 {
}
}
}
}
service {
nat {
rule 10 {
outbound-interface eth0
source {
address 192.168.40.0/24
}
type masquerade
}
}
vpn {
ipsec {
copy-tos disable
esp-group foo {
compression disable
lifetime 3600
mode tunnel
pfs enable
proposal 1 {
encryption aes128
hash sha1
}
}
ike-group foo {
aggressive-mode disable
lifetime 28800
proposal 1 {
encryption aes128
hash sha1
}
}
ipsec-interfaces {
interface eth0
}
site-to-site {
peer 192.168.50.2 {
authentication {
mode pre-shared-secret
pre-shared-secret 12345
}
ike-group foo
local-ip 192.168.70.2
tunnel 1 {
allow-nat-networks disable
allow-public-networks disable
esp-group foo
local-subnet 12.0.0.0/24
remote-subnet 10.0.0.0/24
}
}
}
}
}

The routing tables:

HQ:

adrian@HQ:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.50.1, eth0
O 7.0.0.0/24 [110/10] is directly connected, tun0, 00:38:42
C>* 7.0.0.0/24 is directly connected, tun0
C>* 9.0.0.0/24 is directly connected, lo
C>* 10.0.0.0/24 is directly connected, lo
K>* 11.0.0.0/24 is directly connected, eth0
K>* 12.0.0.0/24 is directly connected, eth0
O 15.0.0.0/24 [110/10] is directly connected, tun1, 00:38:42
C>* 15.0.0.0/24 is directly connected, tun1
C>* 127.0.0.0/8 is directly connected, lo
O 192.168.10.0/24 [110/10] is directly connected, eth1, 00:38:26
C>* 192.168.10.0/24 is directly connected, eth1
O>* 192.168.30.0/24 [110/20] via 7.0.0.2, tun0, 00:38:33
O>* 192.168.40.0/24 [110/20] via 15.0.0.2, tun1, 00:38:29
C>* 192.168.50.0/24 is directly connected, eth0

Branch1:

adrian@Branch1:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.60.1, eth0
O 7.0.0.0/24 [110/10] is directly connected, tun0, 23:37:01
C>* 7.0.0.0/24 is directly connected, tun0
K>* 9.0.0.0/24 is directly connected, eth0
C>* 11.0.0.0/24 is directly connected, lo
O>* 15.0.0.0/24 [110/20] via 7.0.0.1, tun0, 00:40:25
C>* 127.0.0.0/8 is directly connected, lo
O>* 192.168.10.0/24 [110/20] via 7.0.0.1, tun0, 00:40:25
O 192.168.30.0/24 [110/10] is directly connected, eth1, 23:37:07
C>* 192.168.30.0/24 is directly connected, eth1
O>* 192.168.40.0/24 [110/30] via 7.0.0.1, tun0, 00:40:12
C>* 192.168.60.0/24 is directly connected, eth0

Branch2:

adrian@Branch2:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.70.1, eth0
O>* 7.0.0.0/24 [110/20] via 15.0.0.1, tun0, 00:39:20
K>* 10.0.0.0/24 is directly connected, eth0
C>* 12.0.0.0/24 is directly connected, lo
O 15.0.0.0/24 [110/10] is directly connected, tun0, 00:57:58
C>* 15.0.0.0/24 is directly connected, tun0
C>* 127.0.0.0/8 is directly connected, lo
O>* 192.168.10.0/24 [110/20] via 15.0.0.1, tun0, 00:39:20
O>* 192.168.30.0/24 [110/30] via 15.0.0.1, tun0, 00:39:16
O 192.168.40.0/24 [110/10] is directly connected, eth1, 00:58:03
C>* 192.168.40.0/24 is directly connected, eth1
C>* 192.168.70.0/24 is directly connected, eth0

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

My approach(as I configure Cisco routers), see bellow.
Actually, with no IPSec, the GRE tunnels were up and running and I could reach the remote sites.
And I could see with Wireshark the OSPF multicast packets over the tunnels. See the wireshark traces here if you like (OSPF packets and ping connectivity tests).

When I have created the site-to-site connections to protect the GRE tunnels things went wrong.

HQ:

set interfaces ethernet eth0 address 192.168.50.2/24
set interfaces ethernet eth1 address 192.168.10.1/24

set service nat rule 10 type masquerade
set service nat rule 10 source address 192.168.10.0/24
set service nat rule 10 outbound-interface eth0

set protocols static route 0.0.0.0/0 next-hop 192.168.50.1

set interfaces tunnel tun1
set interfaces tunnel tun1 address 192.168.111.1/30
set interfaces tunnel tun1 description "Gre Tunnel to Branch1"
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 192.168.50.2
set interfaces tunnel tun1 remote-ip 192.168.60.2

set interfaces tunnel tun2
set interfaces tunnel tun2 address 192.168.121.1/30
set interfaces tunnel tun2 description "Gre Tunnel to Branch2"
set interfaces tunnel tun2 encapsulation gre
set interfaces tunnel tun2 local-ip 192.168.50.2
set interfaces tunnel tun2 remote-ip 192.168.70.2

set protocols ospf area 100
set protocols ospf area 100 network 192.168.10.0/24
set protocols ospf area 100 network 192.168.111.0/30
set protocols ospf area 100 network 192.168.121.0/30

set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec ike-group IKE-GRE proposal 1
set vpn ipsec ike-group IKE-GRE proposal 1 encryption aes128
set vpn ipsec ike-group IKE-GRE proposal 1 hash sha1
set vpn ipsec ike-group IKE-GRE proposal 1 dh-group 5
set vpn ipsec ike-group IKE-GRE lifetime 28800

set vpn ipsec esp-group ESP-GRE proposal 1
set vpn ipsec esp-group ESP-GRE proposal 1 encryption aes128
set vpn ipsec esp-group ESP-GRE proposal 1 hash sha1
set vpn ipsec esp-group ESP-GRE pfs
set vpn ipsec esp-group ESP-GRE lifetime 3600
set vpn ipsec esp-group ESP-GRE mode transport

set vpn ipsec site-to-site peer 192.168.60.2 authentication mode pre-shared-secret
edit vpn ipsec site-to-site peer 192.168.60.2
set authentication pre-shared-secret 12345
set ike-group IKE-GRE
set local-ip 192.168.50.2
set tunnel 1 local-subnet 192.168.50.2/32
set tunnel 1 remote-subnet 192.168.60.2/32
set tunnel 1 esp-group ESP-GRE

set vpn ipsec site-to-site peer 192.168.70.2 authentication mode pre-shared-secret
edit vpn ipsec site-to-site peer 192.168.70.2
set authentication pre-shared-secret 67890
set ike-group IKE-GRE
set local-ip 192.168.50.2
set tunnel 1 local-subnet 192.168.50.2/32
set tunnel 1 remote-subnet 192.168.70.2/32
set tunnel 1 esp-group ESP-GRE

Branch1

set interfaces ethernet eth0 address 192.168.60.2/24
set interfaces ethernet eth1 address 192.168.30.1/24

set service nat rule 10 type masquerade
set service nat rule 10 source address 192.168.30.0/24
set service nat rule 10 outbound-interface eth0

set protocols static route 0.0.0.0/0 next-hop 192.168.60.1

set interfaces tunnel tun1
set interfaces tunnel tun1 address 192.168.111.2/30
set interfaces tunnel tun1 description "Gre Tunnel to HQ"
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 192.168.60.2
set interfaces tunnel tun1 remote-ip 192.168.50.2

set protocols ospf area 100
set protocols ospf area 100 network 192.168.30.0/24
set protocols ospf area 100 network 192.168.111.0/30

set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec ike-group IKE-GRE proposal 1
set vpn ipsec ike-group IKE-GRE proposal 1 encryption aes128
set vpn ipsec ike-group IKE-GRE proposal 1 hash sha1
set vpn ipsec ike-group IKE-GRE proposal 1 dh-group 5
set vpn ipsec ike-group IKE-GRE lifetime 28800

set vpn ipsec esp-group ESP-GRE proposal 1
set vpn ipsec esp-group ESP-GRE proposal 1 encryption aes128
set vpn ipsec esp-group ESP-GRE proposal 1 hash sha1
set vpn ipsec esp-group ESP-GRE pfs
set vpn ipsec esp-group ESP-GRE lifetime 3600
set vpn ipsec esp-group ESP-GRE mode transport

set vpn ipsec site-to-site peer 192.168.50.2 authentication mode pre-shared-secret
edit vpn ipsec site-to-site peer 192.168.50.2
set authentication pre-shared-secret 12345
set ike-group IKE-GRE
set local-ip 192.168.60.2
set tunnel 1 local-subnet 192.168.60.2/32
set tunnel 1 remote-subnet 192.168.50.2/32
set tunnel 1 esp-group ESP-GRE

Branch2:

set interfaces ethernet eth0 address 192.168.70.2/24
set interfaces ethernet eth1 address 192.168.40.1/24

set service nat rule 10 type masquerade
set service nat rule 10 source address 192.168.40.0/24
set service nat rule 10 outbound-interface eth0

set protocols static route 0.0.0.0/0 next-hop 192.168.70.1

set interfaces tunnel tun1
set interfaces tunnel tun1 address 192.168.121.2/30
set interfaces tunnel tun1 description "Gre Tunnel to HQ"
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 192.168.70.2
set interfaces tunnel tun1 remote-ip 192.168.50.2

set protocols ospf area 100
set protocols ospf area 100 network 192.168.40.0/24
set protocols ospf area 100 network 192.168.121.0/30

set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec ike-group IKE-GRE proposal 1
set vpn ipsec ike-group IKE-GRE proposal 1 encryption aes128
set vpn ipsec ike-group IKE-GRE proposal 1 hash sha1
set vpn ipsec ike-group IKE-GRE proposal 1 dh-group 5
set vpn ipsec ike-group IKE-GRE lifetime 28800

set vpn ipsec esp-group ESP-GRE proposal 1
set vpn ipsec esp-group ESP-GRE proposal 1 encryption aes128
set vpn ipsec esp-group ESP-GRE proposal 1 hash sha1
set vpn ipsec esp-group ESP-GRE pfs
set vpn ipsec esp-group ESP-GRE lifetime 3600
set vpn ipsec esp-group ESP-GRE mode transport

set vpn ipsec site-to-site peer 192.168.50.2 authentication mode pre-shared-secret
edit vpn ipsec site-to-site peer 192.168.50.2
set authentication pre-shared-secret 67890
set ike-group IKE-GRE
set local-ip 192.168.70.2
set tunnel 1 local-subnet 192.168.70.2/32
set tunnel 1 remote-subnet 192.168.50.2/32
set tunnel 1 esp-group ESP-GRE

stig · Posted: Sat Mar 15, 2008 11:28 am Post subject:

Hi Adrian,

Glad to hear you got it working. When I was initially try to get my setup to work I kept running into a problem with the interface route that the vpn package automatically adds. For example if I say the ipsec interface is ethX and the remote network for the tunnel is x.x.x.x/y, then openswan will add a static interface route for x.x.x.x/y out interface ethX (in "show ip route" it shows up as a "K>" kernel route). For some of the setups I tried, simply removing this interface route would solve the problem, but I didn't want to have a separate step outside of the vyatta cli. That's why I used a different network on the loopback for my end points.

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

Hi Stig,
As said in my first post, the kernel route spoiled my party.
I thought I must have done something wrong.
For example in case of the HQ router(using the commands I've posted above), once the site-to-site connections are configured, the kernel routes appear and I can see ARP requests sent from the external IP address 192.168.50.2 to 192.168.60.2 and 192.168.7.0.2.

adrian@HQ:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.50.1, eth0
C>* 127.0.0.0/8 is directly connected, lo
O 192.168.10.0/24 [110/10] is directly connected, eth1, 00:01:39
C>* 192.168.10.0/24 is directly connected, eth1
C>* 192.168.50.0/24 is directly connected, eth0
K>* 192.168.60.2/32 is directly connected, eth0
K>* 192.168.70.2/32 is directly connected, eth0
O 192.168.111.0/30 [110/10] is directly connected, tun1, 00:01:34
C>* 192.168.111.0/30 is directly connected, tun1
O 192.168.121.0/30 [110/10] is directly connected, tun2, 00:01:34
C>* 192.168.121.0/30 is directly connected, tun2

Interesting to see how it would interoperate Glendale(loopback scenario) with Cisco routers(using loopback interfaces too).

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

Just in case somebody would be interested:
I did a quick test today with a Glendale and a Cisco 3620 router.
Glendale------Cisco
And it does not work(using loopback interfaces).
I'm stuck in IKE phase II(quick mode).
If I swap Glendale with another 3620 and "mirror" Glendale's config it works.
If I swap 3620 with another Glendale and "mirror" 3620's config it works.
The Cisco router is saying:IPSEC(validate_transform_proposal): proxy identities not supported.
So I would think that I've misconfigured the crypto ACL or Glendale's site-to-site subnets.
But they appear to be fine(the swapping seems to show this).
Interesting, if I change the crypto acl from(replace gre with ip):
access-list 101 permit gre ....
to
access-list 101 permit ip ....
then IKE phase II completes and I can see Glendale sending some ESP packets.
However, since probably those ESP packets contain GRE traffic, the Cisco router does not respond(the acl says ip).
So actually it seems that the subnets are correctly configured.
But the crypto acl cannot be truly mirrored on Glendale's side(there is no gre parameter).
At a glance it looks that this thing makes the Cisco router unhappy.

stig · Posted: Sun Mar 16, 2008 12:33 pm Post subject:

Adrian,

The following link is someone using openswan to connect to a cisco with GRE over ipsec:

http://mailman.ds9a.nl/pipermail/lartc/2006q3/019269.html

It looks like the approach they took was to delete the interface route that openswan adds to the kernel.

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

Hi Stig,
Thanks for your answer.
Yep I can delete that route.
But that does not seem to fix the IKE Phase II issue.
So it appears that the Cisco router needs a Quick Mode filter for GRE protocol(47) and it does not get it from Glendale(either with tunnel or transport mode).
Glendale proposes a value of zero which means that the Protocol ID field should be ignored.
And that makes the Cisco router unhappy.

R0#show access-lists
Extended IP access list 101
10 permit gre 192.168.100.0 0.0.0.255 192.168.111.0 0.0.0.255 (315 matches)
In that link they did not mention what crypto acl they use on the Cisco router.

Here is what the Cisco router is saying:

interface: FastEthernet0/0
Crypto map tag: GRE, local addr. 192.168.50.1
protected vrf:
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/47/0)
remote ident (addr/mask/prot/port): (192.168.111.0/255.255.255.0/47/0)
current_peer: 192.168.50.2:500

*Mar 1 00:04:36.867: IPSEC(key_engine): request timer fired: count = 2,
(identity) local= 192.168.50.1, remote= 192.168.50.2,
local_proxy= 192.168.100.0/255.255.255.0/47/0 (type=4),
remote_proxy= 192.168.111.0/255.255.255.0/47/0 (type=4)
*Mar 1 00:04:46.867: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 192.168.50.1, remote= 192.168.50.2,
local_proxy= 192.168.100.0/255.255.255.0/47/0 (type=4),
remote_proxy= 192.168.111.0/255.255.255.0/47/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x6817655E(1746363742), conn_id= 0, keysize= 128, flags= 0x400E

*Mar 1 00:04:47.971: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 192.168.50.1, remote= 192.168.50.2,
local_proxy= 192.168.100.0/255.255.255.0/0/0 (type=4),
remote_proxy= 192.168.111.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
*Mar 1 00:04:47.971: IPSEC(kei_proxy): head = GRE, map->ivrf = , kei->ivrf =
*Mar 1 00:04:47.971: IPSEC(validate_transform_proposal): proxy identities not supported
*Mar 1 00:04:57.979: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 192.168.50.1, remote= 192.168.50.2,
local_proxy= 192.168.100.0/255.255.255.0/0/0 (type=4),
remote_proxy= 192.168.111.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
*Mar 1 00:04:57.979: IPSEC(kei_proxy): head = GRE, map->ivrf = , kei->ivrf =
*Mar 1 00:04:57.979: IPSEC(validate_transform_proposal): proxy identities not supported
*Mar 1 00:04:57.979: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 192.168.50.2

*Mar 1 00:18:37.315: ISAKMP: Checking IPSec proposal 0
*Mar 1 00:18:37.315: ISAKMP: transform 0, ESP_AES
*Mar 1 00:18:37.315: ISAKMP: attributes in transform:
*Mar 1 00:18:37.315: ISAKMP: group is 5
*Mar 1 00:18:37.315: ISAKMP: encaps is 1 (Tunnel)
*Mar 1 00:18:37.315: ISAKMP: SA life type in seconds
*Mar 1 00:18:37.315: ISAKMP: SA life duration (basic) of 3600
*Mar 1 00:18:37.315: ISAKMP: authenticator is HMAC-SHA
*Mar 1 00:18:37.315: ISAKMP: key length is 128
*Mar 1 00:18:37.315: ISAKMP : atts are acceptable.

*Mar 1 00:18:37.315: ISAKMP: Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
*Mar 1 00:18:37.315: ISAKMP: phase 2 SA policy not acceptable! (local 192.168.50.1 remote 192.168.50.2)
*Mar 1 00:18:37.315: ISAKMP: deleting node -2065258163 error TRUE reason "quick mode rejected"

Wait a minute, I think I solved it.

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

I've changed the crypto acl from:
access-list 101 permit gre 192.168.100.0 0.0.0.255 192.168.111.0 0.0.0.255
to
access-list 101 permit 0 192.168.100.0 0.0.0.255 192.168.111.0 0.0.0.255
And it seems to work.

So the Cisco config(3620 12.3) looks like this:

int f0/0
ip address 192.168.50.1 255.255.255.0
crypto map GRE

int f1/0
ip address 192.168.10.1 255.255.255.0

interface Loopback1
ip address 192.168.100.1 255.255.255.0

interface Tunnel0
ip address 192.168.200.1 255.255.255.0
tunnel source Loopback1
tunnel destination 192.168.111.1

ip route 0.0.0.0 0.0.0.0 192.168.50.2

router ospf 10
network 192.168.10.0 0.0.0.255 area 0
network 192.168.200.0 0.0.0.255 area 0

crypto isakmp policy 25
hash sha
encr aes 128
group 5
lifetime 28800
authentication pre-share
crypto isakmp key 12345 address 192.168.50.2

crypto ipsec transform-set test esp-aes 128 esp-sha-hmac

crypto map GRE 50 ipsec-isakmp
set peer 192.168.50.2
set transform-set test
set pfs group5
match address 101

access-list 101 permit 0 192.168.100.0 0.0.0.255 192.168.111.0 0.0.0.255

And Glendale config:

set interfaces ethernet eth0 address 192.168.50.2/24
set interfaces ethernet eth1 address 192.168.30.1/24

set protocols static route 0.0.0.0/0 next-hop 192.168.50.1

set interfaces loopback lo address 192.168.111.1/24

set interfaces tunnel tun1
set interfaces tunnel tun1 address 192.168.200.2/24
set interfaces tunnel tun1 description "Gre Tunnel to Cisco"
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 192.168.111.1
set interfaces tunnel tun1 remote-ip 192.168.100.1

set protocols ospf area 0
set protocols ospf area 0 network 192.168.30.0/24
set protocols ospf area 0 network 192.168.200.0/24

set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec ike-group IKE-GRE proposal 1
set vpn ipsec ike-group IKE-GRE proposal 1 encryption aes128
set vpn ipsec ike-group IKE-GRE proposal 1 hash sha1
set vpn ipsec ike-group IKE-GRE proposal 1 dh-group 5
set vpn ipsec ike-group IKE-GRE lifetime 28800

set vpn ipsec esp-group ESP-GRE proposal 1
set vpn ipsec esp-group ESP-GRE proposal 1 encryption aes128
set vpn ipsec esp-group ESP-GRE proposal 1 hash sha1
set vpn ipsec esp-group ESP-GRE pfs
set vpn ipsec esp-group ESP-GRE lifetime 3600

set vpn ipsec site-to-site peer 192.168.50.1 authentication mode pre-shared-secret
edit vpn ipsec site-to-site peer 192.168.50.1
set authentication pre-shared-secret 12345
set ike-group IKE-GRE
set local-ip 192.168.50.2
set tunnel 1 local-subnet 192.168.111.0/24
set tunnel 1 remote-subnet 192.168.100.0/24
set tunnel 1 esp-group ESP-GRE

And the routing tables:
(as you can see I've deleted the kernel route)
adrian@HQ:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.50.1, eth0
C>* 127.0.0.0/8 is directly connected, lo
O>* 192.168.10.0/24 [110/11] via 192.168.200.1, tun1, 00:11:30
O 192.168.30.0/24 [110/10] is directly connected, eth1, 01:13:37
C>* 192.168.30.0/24 is directly connected, eth1
C>* 192.168.50.0/24 is directly connected, eth0
C>* 192.168.111.0/24 is directly connected, lo
O 192.168.200.0/24 [110/10] is directly connected, tun1, 01:13:32
C>* 192.168.200.0/24 is directly connected, tun1

R0#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.50.2 to network 0.0.0.0

O 192.168.30.0/24 [110/11121] via 192.168.200.2, 00:08:32, Tunnel0
C 192.168.10.0/24 is directly connected, FastEthernet1/0
C 192.168.200.0/24 is directly connected, Tunnel0
C 192.168.50.0/24 is directly connected, FastEthernet0/0
C 192.168.100.0/24 is directly connected, Loopback1
S* 0.0.0.0/0 [1/0] via 192.168.50.2

I have connectivity from both sites. So it looks like it's working. Need more tests though.
Best,
Adrian

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

By the way, I do not have to delete the kernel route when using loopback interfaces.
I've rebooted both systems and things look good. The IPsec tunnel came up as expected with no errors.

adrian@HQ:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 192.168.50.1, eth0
C>* 127.0.0.0/8 is directly connected, lo
O>* 192.168.10.0/24 [110/11] via 192.168.200.1, tun1, 00:00:42
O 192.168.30.0/24 [110/10] is directly connected, eth1, 00:00:58
C>* 192.168.30.0/24 is directly connected, eth1
C>* 192.168.50.0/24 is directly connected, eth0
K>* 192.168.100.0/24 is directly connected, eth0
C>* 192.168.111.0/24 is directly connected, lo
O 192.168.200.0/24 [110/10] is directly connected, tun1, 00:00:53
C>* 192.168.200.0/24 is directly connected, tun1

The Cisco router says:
*Mar 1 00:02:47.287: %OSPF-5-ADJCHG: Process 10, Nbr 192.168.111.1 on Tunnel0 from LOADING to FULL, Loading Done

stig · Posted: Sun Mar 16, 2008 6:34 pm Post subject:

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

by the way, it seems that IPsec ESP in transport mode "it's not working" on Glendale.
Analyzing with Wireshark the packets and it looks like the numbers are not matching(packets are bigger than expected).
For example send a packet.
On the router it gets GRE encapsulated and a new IP header is appended with the end-points of the GRE tunnel.
This new packet minus the new IP header is protected by IPsec ESP in transport mode, the IPsec ESP header is introduced between the protected payload and the new IP header.
Configured Glendale with GRE tunnel endpoints corresponding to the physical interfaces, deleted the kernel route, specified transport mode.
But instead tunnel mode appears to be used.
I've set ESP confidentiality to null on Glendale and I can clearly see this thing.
The entire new packet including the new IP header is protected by ESP, just like in case of tunnel mode (the position of the ESP header shows this). And a new IP header is appended.
It is desirable to use GRE+IPsec in transport mode when the tunnel endpoints are public IP addresses, because tunnel mode adds an unnecessary 20 bytes of overhead by encapsulating the entire packet resulted after the GRE encapsulation.
When we are using GRE with loopback interfaces with private IP addresses on them and these loopback interfaces serve as GRE tunnel endpoints we need tunnel mode, but in the above case it would be recommended to use transport mode.

stig · Posted: Sun Mar 23, 2008 10:22 am Post subject: Gre over IPsec

We should probably ask users@openswan.org (users@openswan.org) to see if this is a known issue with version 2.4.8.

From: adriand [mailto:forum-users@vyatta.com]
Sent: Sunday, March 23, 2008 10:42 AM
To: forum-users@vyatta.com
Subject: [Vyatta-users] Re: Gre over IPsec

by the way, it seems that IPsec ESP in transport mode "it's not working" on Glendale.
I've made some traffic analysis and looks like the numbers are not matching.
For example send a packet.
On the router it gets GRE encapsulated and a new IP header is appended with the end-points of the tunnel.
This new packet minus the new IP header is protected by IPsec ESP in transport mode, the IPsec ESP header is introduced between the protected payload and the new IP header.
Configured Glendale with GRE tunnel endpoints corresponding to the physical interfaces, delete the kernel route, specified transport mode.
But instead tunnel mode is used.
I've set ESP confidentiality to null on Glendale and I can clearly see this thing.
The entire new packet including the new IP header is protected by ESP, just like in case of tunnel mode (the position of the ESP header shows this). And a new IP header is appended.
It is desirable to use GRE+IPsec in transport mode when the tunnel endpoints are public IP addresses, because tunnel mode adds an unnecessary 20 bytes of overhead by encapsulating the entire packet resulted after the GRE encapsulation.
When we are using GRE with loopback interfaces with private IP addresses on them and these loopback interfaces serve as GRE tunnel endpoints we need tunnel mode, but in the above case it would be recommended to use transport mode.

adriand · Forum Veteran Joined: 14 Mar 2008 Posts: 119

Hi Stig,
You can view the Wireshark capture with ESP confidentiality set to null on Glendale here if you want. It's a little bit messed at the beginning until I've set the ESP confidentiality to null on both Glendales.
Don't forget to instruct Wireshark to decode NULL encrypted ESP payloads.
On Glendale, in /etc/ipsec.conf I've set "esp=null-md5". Here also I can see that "type=transport".
Asking there would imply to be a subscriber of the respective mailing list. Very Happy

By the way, if I test with Glendale and a Cisco router(not with loopback interfaces, GRE tunnel endpoints the IP addresses of the physical interfaces), the Cisco router also tells me that "tunnel" is used and not "transport".