Gre over IPsec

37 posts / 0 new
Last post
adriand
Gre over IPsec

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
Gre over IPsec

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.

     +----------+                                    +----------+
     |          |                                    |          |
 eth0|          |eth1                            eth0|          |eth1
-----+ router-A +-------------  INTERNET ------------+ router-B +-----
     |          |                                    |          |
     |          |                                    |          |
     +----+-----+                                    +----+-----+
          |                                               |
          |lo0                                            |lo0

  

router-A
========

interfaces {
    ethernet eth0 {
        address "172.16.117.128/24"
        hw-id: 00:0c:29:b0:1d:bb
    }
    ethernet eth1 {
        address "192.168.249.128/24"
        hw-id: 00:0c:29:b0:1d:d9
    }
    loopback lo {
        address "9.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
    }
}
protocols {
    ospf {
        area 0 {
            network 172.16.117.0/24
            network 7.0.0.0/24
        }
        log-adjacency-changes {
        }
        parameters {
            router-id: 9.0.0.1
        }
        redistribute {
            connected {
            }
        }
    }
    static {
        route 172.16.139.0/24 {
            next-hop 192.168.249.150 {
            }
        }
    }
}
vpn {
    ipsec {
        esp-group foo {
            proposal 1 {
            }
        }
        ike-group foo {
            proposal 1 {
            }
        }
        ipsec-interfaces {
            interface "eth1"
        }
        logging {
            facility: daemon
            level: info
        }
        site-to-site {
            peer 172.16.139.160 {
                authentication {
                    pre-shared-secret: "testing123"
                }
                ike-group: "foo"
                local-ip: 192.168.249.128
                tunnel 1 {
                    esp-group: "foo"
                    local-subnet: 9.0.0.0/24
                    remote-subnet: 11.0.0.0/24
                }
            }
        }
    }
}





router-B
========

interfaces {
    ethernet eth0 {
        address "172.16.139.160/24"
        hw-id: 00:0c:29:df:17:97
    }
    ethernet eth1 {
        address "192.168.74.160/24"
        hw-id: 00:0c:29:df:17:a1
    }
    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
    }
}
protocols {
    ospf {
        area 0 {
            network 192.168.74.0/24
            network 7.0.0.0/24
        }
        log-adjacency-changes {
        }
        parameters {
            router-id: 11.0.0.1
        }
        redistribute {
            connected {
            }
        }
    }
    static {
        route 192.168.249.0/24 {
            next-hop 172.16.139.150 {
            }
        }
    }
}
vpn {
    ipsec {
        esp-group foo {
            proposal 1 {
            }
        }
        ike-group foo {
            proposal 1 {
            }
        }
        ipsec-interfaces {
            interface "eth0"
        }
        site-to-site {
            peer 192.168.249.128 {
                authentication {
                    pre-shared-secret: "testing123"
                }
                ike-group: "foo"
                local-ip: 172.16.139.160
                tunnel 1 {
                    esp-group: "foo"
                    local-subnet: 11.0.0.0/24
                    remote-subnet: 9.0.0.0/24
                }
            }
        }
    }
}
adriand
Gre over IPsec

Hi Stig,
You're a natural superstar! 8)
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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

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
Gre over IPsec

adriand wrote:
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.

Great news and thanks for posting your example configurations - I'm sure they'll be very helpful to the next person who trys to inter-operate with a cisco box.

adriand
Gre over IPsec

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
Gre over IPsec

We should probably ask

(

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

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
Gre over IPsec

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. :D
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".

stig
Gre over IPsec

adriand wrote:
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.

Adrian,

I did a bit more research on transport mode yesterday in Paul Wouter's book "Building and Integrating Virtual Private Networks with Openswan". Apparently transport mode will only be used if it's a host-to-host connection and not if "leftsubnet/rightsubnet" are defined. Currently the vyatta cli requires those subnets, so I tried a quick test to manually edit the /etc/ipsec.conf file to remove those subnets and then was able to see transport mode for the host-to-host tunnel. Unfortunately the gre tunnel was not working on top of the new ipsec tunnel, so I have some more work to do to figure out that configuration.

An interesting side note is that the book I mentioned above basically says the only time you should use transport mode is with L2TP. Below is a quote from page 35 of that book:

Paul Wouter wrote:
Even if you are setting up a host to host connection, you should use tunnel mode, so that all the IP options of the packet can be encapsulated and encryted. In fact, two well know people in the cryptography world, Bruce Schneier and Niels Ferguson, have argued for AH and transport mode to be got rid of altogether.
adriand
Gre over IPsec

Hi Stig,
I see.
My concern regarding the use of transport mode vs tunnel with GRE tunnels was MTU due to packet overhead(4 byte GRE header + 20 bytes for the new IP header introduced by tunnel mode).
Actually in the same book, there is a diagram showing how it will look a packet over the wire resulted from GRE+IPsec, and that diagram describes IPsec transport mode. :)
See Chapter 11, Reducing the Number of tunnels section.
Payload | IP Header | GRE Header | IPsec Header | IP Header
Tunnel mode will look like:
Payload | IP Header | GRE Header | IP Header | IPsec Header | IP Header
I'm not a cryptographer, but I can see in RFC4303, "an Internet Standard", that transport mode is there as it was in RFC2406, another "Internet Standard".
With GRE tunnels, "like" in case of L2TP, we already have a "tunnel".
So packets are traveling inside the GRE tunnel. Every packet sent between the sites gets GRE encapsulated and the new IP header with source and destination IP addresses of the GRE tunnel is appended after the 4 byte GRE header.
So we have a point-to-point connection.
Just like in case of L2TP, we need to secure a tunnel, the GRE tunnel. After the GRE encapsulation we are left with a GRE IP packet.
So we have a "special" kind of host to host connection.
In IKE QM, we can negotiate to protect the GRE protocol(set the Protocol ID field appropiately and not to 0), because only GRE traffic needs to be protected.
If the GRE tunnel endpoints and IPsec peers addresses are the same, IMHO, transport mode should be enough. The new IP header introduced by tunnel mode is also unprotected.
Actually the IP header in case of transport mode is not quite the original one of the GRE tunnel, because the original one had the Protocol field set to GRE.
Since I'm not a cryptographer I can say if we achieve or not something using tunnel mode in our situation.
So I'm not sure that we are in the never ending situation of functionality versus security.
In RFC3884, not a standard of any kind, they describe the use of IPIP+IPsec in transport mode for dynamic routing:
http://www.ietf.org/rfc/rfc4303.txt
In the bellow document, some people from Juniper, Nortel and USC/ISI analyze the need of dynamic routing for IPsec VPNs, and various implementations to acheive this(GRE, IPIP....):
http://isi.edu/div7/presentation_files/dynamic_routing.pdf
They mention transport mode of being more "efficient" over tunnel mode in case of GRE.
Cisco in general also recommendeds the use of transport mode(they use it for DMVPN too). OK, Cisco also proposed XAUTH or LEAP.
However in this document, as general best practices, Cisco recommends the use of IPsec tunnel mode for best flexibility. And Cisco acknowledges that the use of transport mode or tunnel mode has been the subject of a debate:
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008073a0c5.pdf
Regarding the concern of overhead from the use of GRE for the system, IMHO, in case of Vyatta this is a relative thing, because Vyatta runs on modern hardware, and can easily scale vertically if needed.
In general these two issues are widely discussed about GRE tunnels: system overhead due to GRE encapulation and packet overhead again due to GRE encapsulation.
I know that Juniper fellows always jump up with joy saying they don't need GRE for dynamic VPNs because they've implemented IPsec as a routable interface.
However, GRE, like L2TP, can carry non-IP traffic also.

stig
Gre over IPsec

Hi Adrian,

I guess it's clear that even amongst the experts there isn't consensus's on whether to use transport or tunnel mode, so we should probably support both. Given that I was able to get transport mode working by just removing the leftsubnet/rightsubnet statements, then I really think we should be able to get the GRE part working too with the right config. I'm not sure how much time I'll have to play with this in the near term, but I'll at least open a bug to track that there are vyatta cli changes necessary to get transport mode working without leftsubnet/rightsubnet (http://bugzilla.vyatta.com/show_bug.cgi?id=3046). If you happen to get a working config before me that'd be cool too. ;-)

BTW, this bug should count toward Dave's bug hunt contest [url]http://www.vyatta.org/node/6]

adriand wrote:
Hi Stig,
I see.
My concern regarding the use of transport mode vs tunnel with GRE tunnels was MTU due to packet overhead(4 byte GRE header + 20 bytes for the new IP header introduced by tunnel mode).
Actually in the same book, there is a diagram showing how it will look a packet over the wire resulted from GRE+IPsec, and that diagram describes IPsec transport mode. :)
See Chapter 11, Reducing the Number of tunnels section.
Payload | IP Header | GRE Header | IPsec Header | IP Header
Tunnel mode will look like:
Payload | IP Header | GRE Header | IP Header | IPsec Header | IP Header
I'm not a cryptographer, but I can see in RFC4303, "an Internet Standard", that transport mode is there as it was in RFC2406, another "Internet Standard".
With GRE tunnels, "like" in case of L2TP, we already have a "tunnel".
So packets are traveling inside the GRE tunnel. Every packet sent between the sites gets GRE encapsulated and the new IP header with source and destination IP addresses of the GRE tunnel is appended after the 4 byte GRE header.
So we have a point-to-point connection.
Just like in case of L2TP, we need to secure a tunnel, the GRE tunnel. After the GRE encapsulation we are left with a GRE IP packet.
So we have a "special" kind of host to host connection.
In IKE QM, we can negotiate to protect the GRE protocol(set the Protocol ID field appropiately and not to 0), because only GRE traffic needs to be protected.
If the GRE tunnel endpoints and IPsec peers addresses are the same, IMHO, transport mode should be enough. The new IP header introduced by tunnel mode is also unprotected.
Actually the IP header in case of transport mode is not quite the original one of the GRE tunnel, because the original one had the Protocol field set to GRE.
Since I'm not a cryptographer I can say if we achieve or not something using tunnel mode in our situation.
So I'm not sure that we are in the never ending situation of functionality versus security.
In RFC3884, not a standard of any kind, they describe the use of IPIP+IPsec in transport mode for dynamic routing:
http://www.ietf.org/rfc/rfc4303.txt
In the bellow document, some people from Juniper, Nortel and USC/ISI analyze the need of dynamic routing for IPsec VPNs, and various implementations to acheive this(GRE, IPIP....):
http://isi.edu/div7/presentation_files/dynamic_routing.pdf
They mention transport mode of being more "efficient" over tunnel mode in case of GRE.
Cisco in general also recommendeds the use of transport mode(they use it for DMVPN too). OK, Cisco also proposed XAUTH or LEAP.
However in this document, as general best practices, Cisco recommends the use of IPsec tunnel mode for best flexibility. And Cisco acknowledges that the use of transport mode or tunnel mode has been the subject of a debate:
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008073a0c5.pdf
Regarding the concern of overhead from the use of GRE for the system, IMHO, in case of Vyatta this is a relative thing, because Vyatta runs on modern hardware, and can easily scale vertically if needed.
In general these two issues are widely discussed about GRE tunnels: system overhead due to GRE encapulation and packet overhead again due to GRE encapsulation.
I know that Juniper fellows always jump up with joy saying they don't need GRE for dynamic VPNs because they've implemented IPsec as a routable interface.
However, GRE, like L2TP, can carry non-IP traffic also.
adriand
Gre over IPsec

Hi Stig,
In fact I do have a working config with GRE+IPsec Transport Mode with Glendale Alpha2.
As you said, I've removed the leftsubnet/rightsubnet from /etc/ipsec.conf and set esp="null-sha1" in order to see inside the "tunnel".
And it appears that now transport mode is used.
My config looks like an usual one with cisco routers, no loopback interfaces, GRE tunnel endpoinds addresses are the same with the IPsec peers addresses(from the physical interfaces).
|-Branch1
|
|
|-HQ
|
|
|-Branch1
I did not tried with a more realistic config(like putting a router between these one). I suppose in that case, I will really have to delete the kernel routes(in this test, since the routers are directly connected, it worked with the kernel routes and without them).
If we want to use transport mode with loopback interfaces, we need "public IP" addresses on them, and this public IP addresses to serve as GRE tunnel endpoinds addresses and IPsec peers addresses. I did not tried that with Glendale. Did that with Cisco routers(the ipsec interface is the external physical interface).
First I've started only HQ and Branch1. And it went fine.
Then I've started Branch2. Things looked good too.
If you want you can take a look at the Wireshark traces here (two routers, two routers for about 45 min, three routers).

So the config for HQ and Branch1 were(I will not post the config for Branch2 because it will make this post too long):

HQ:

 interfaces {
     ethernet eth0 {
         address 192.168.50.2/24
         duplex auto
         hw-id 00:0c:29:50:ae:98
         speed auto
     }
     ethernet eth1 {
         address 192.168.10.1/24
         duplex auto
         hw-id 00:0c:29:50:ae:a2
         speed auto
     }
     loopback lo {
     }
     tunnel tun1 {
         address 192.168.111.1/24
         description "Gre Tunnel to Branch1"
         encapsulation gre
         local-ip 192.168.50.2
         remote-ip 192.168.50.3
         ttl 255
     }
     tunnel tun2 {
         address 192.168.121.1/24
         description "Gre Tunnel to Branch2"
         encapsulation gre
         local-ip 192.168.50.2
         remote-ip 192.168.50.4
         ttl 255
     }
 }
 protocols {
     ospf {
         area 100 {
             network 192.168.10.0/24
             network 192.168.111.0/24
             network 192.168.121.0/24
         }
     }
     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
         }
     }
     ssh {
         port 22
         protocol-version 2
     }
 }
 system {
     host-name HQ
     login {
         user root {
             authentication {
                 encrypted-password $1$$Ht7gBYnxI1xCdO/JOnodh.
             }
             level admin
         }
         user vyatta {
             authentication {
                 encrypted-password $1$$Ht7gBYnxI1xCdO/JOnodh.
             }
             level admin
         }
     }
     ntp-server 69.59.150.135
     package {
         auto-sync 1
         repository community {
             components main
             distribution community
             url http://archive.vyatta.com/vyatta
         }
     }
     time-zone GMT
 }
 vpn {
     ipsec {
         copy-tos disable
         esp-group ESP-GRE {
             compression disable
             lifetime 3600
             mode transport
             pfs enable
             proposal 1 {
                 encryption aes128
                 hash sha1
             }
         }
         ike-group IKE-GRE {
             aggressive-mode disable
             lifetime 28800
             proposal 1 {
                 dh-group 5
                 encryption aes128
                 hash sha1
             }
         }
         ipsec-interfaces {
             interface eth0
         }
         site-to-site {
             peer 192.168.50.3 {
                 authentication {
                     mode pre-shared-secret
                     pre-shared-secret 12345
                 }
                 ike-group IKE-GRE
                 local-ip 192.168.50.2
                 tunnel 1 {
                     allow-nat-networks disable
                     allow-public-networks disable
                     esp-group ESP-GRE
                     local-subnet 192.168.50.2/32
                     remote-subnet 192.168.50.3/32
                 }
             }
             peer 192.168.50.4 {
                 authentication {
                     mode pre-shared-secret
                     pre-shared-secret 67890
                 }
                 ike-group IKE-GRE
                 local-ip 192.168.50.2
                 tunnel 1 {
                     allow-nat-networks disable
                     allow-public-networks disable
                     esp-group ESP-GRE
                     local-subnet 192.168.50.2/32
                     remote-subnet 192.168.50.4/32
                 }
             }
         }
     }
 }


Branch1:
 interfaces {
     ethernet eth0 {
         address 192.168.50.3/24
         duplex auto
         hw-id 00:0c:29:1f:c0:e9
         speed auto
     }
     ethernet eth1 {
         address 192.168.30.1/24
         duplex auto
         hw-id 00:0c:29:1f:c0:f3
         speed auto
     }
     loopback lo {
     }
     tunnel tun1 {
         address 192.168.111.2/24
         description "Gre Tunnel to HQ"
         encapsulation gre
         local-ip 192.168.50.3
         remote-ip 192.168.50.2
         ttl 255
     }
 }
 protocols {
     ospf {
         area 100 {
             network 192.168.30.0/24
             network 192.168.111.0/24
         }
     }
     static {
         route 0.0.0.0/0 {
             next-hop 192.168.50.1 {
             }
         }
     }
 }
 service {
     nat {
         rule 10 {
             outbound-interface eth0
             source {
                 address 192.168.30.0/24
             }
             type masquerade
         }
     }
     ssh {
         port 22
         protocol-version 2
     }
 }
 system {
     host-name Branch1
     login {
         user root {
             authentication {
                 encrypted-password $1$$Ht7gBYnxI1xCdO/JOnodh.
             }
             level admin
         }
         user vyatta {
             authentication {
                 encrypted-password $1$$Ht7gBYnxI1xCdO/JOnodh.
             }
             level admin
         }
     }
     ntp-server 69.59.150.135
     package {
         auto-sync 1
         repository community {
             components main
             distribution community
             url http://archive.vyatta.com/vyatta
         }
     }
     time-zone GMT
 }
 vpn {
     ipsec {
         copy-tos disable
         esp-group ESP-GRE {
             compression disable
             lifetime 3600
             mode transport
             pfs enable
             proposal 1 {
                 encryption aes128
                 hash sha1
             }
         }
         ike-group IKE-GRE {
             aggressive-mode disable
             lifetime 28800
             proposal 1 {
                 dh-group 5
                 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 IKE-GRE
                 local-ip 192.168.50.3
                 tunnel 1 {
                     allow-nat-networks disable
                     allow-public-networks disable
                     esp-group ESP-GRE
                     local-subnet 192.168.50.3/32
                     remote-subnet 192.168.50.2/32
                 }
             }
         }
     }
 }


Regarding that bug contest, I'm not a fan of such contests. I hope Dave does not mind and cuts me off the list.

stig
Gre over IPsec

Hi Adrian,

Glad to hear you got it working with transport mode and thanks for posting the configs. I'll let you know when bug 3046 is fixed and I'll try to get that in before the official glendale release.

adriand
Gre over IPsec

BTW, dpd with dpdaction=restart looks messy.
For example, in case of gre/ipsec, I can see with Wireshark that when the remote host becomes unreachable, Vyatta VC4 Beta tries to restart the VPN connection (new IKE MM).
However, the old ISAKMP and IPsec SAs are not deleted. Or sometimes just the ISAKMP SA is cleared. So a new IKE MM packet is send and also ESP packets continue to be sent (the IPsec encapsulated OSPF Hello messages) - which is pretty pointless and resource consuming. Or a new IKE QM packet is send along with the ESP packets(OSPF Hello messages).
When I re-establish connectivity, the VPN tunnel is restarted(first in case the old IPsec SA is still there, ESP packets flow using the old SA, and after a couple of seconds new IKE MM negotiations are initiated followed by IKE QM ones, so dpd was kinda useless).

It looks more stable to use dpdaction=hold. Here the old ISAKMP and IPsec SAs are deleted. And due to the OSPF Hello messages new IKE MM negotiations are attempted from both sides.
Now, when I re-establish connectivity, the VPN tunnel is indeed restarted (new IKE MM negotiations are initiated followed by IKE QM ones).

My test platform(// = connectivity loss):
Vyatta VC4(gre/ipsec)-----Vyatta VC4-----//------Vyatta VC4------Vyatta VC4(gre/ipsec)

stig
Gre over IPsec

Hi Adrian,

Thanks for the info on dpd - you're definitely a power-user when it comes to vpn.

BTW, earlier in this thread you found a bug with transport mode (https://bugzilla.vyatta.com/show_bug.cgi?id=3046). I was able to get the fix committed before the window closed for VC4, so when the official VC4 build is released (real soon now) you should be able to configure a transport mode tunnel without local/remote subnets. The other issue is the interface route that gets added and I still haven't found a way to prevent that. :(

adriand
Gre over IPsec

Hi Stig,
Great news about ESP in transport mode.
I think it's not wrong to suppose that people are used to configure gre/ipsec with ESP in transport mode(I was reading some docs on juniper's site and there, the configuration examples for gre/ipsec use ESP in transport mode too), and that they will try to do the same thing with Vyatta now that it has support for gre/ipsec.
If the kernel route spoils the party, well, I think that as long there is a working configuration(although it adds some config overhead), things might look good if someone needs the advanced features of gre/ipsec or ipip/ipsec. Not sure what will be the performance numbers between the working config and the one using ESP in transport mode.
Actually I do not think I've read a paper regarding Vyatta's VPN performance/throughput.
Yep, VPN is my favourite topic :D (next in line is firewall stuff).

adriand
Gre over IPsec

Hi Stig,
Just to let you know, I've downloaded VC4 final and tested ESP transport mode + Gre tunnels.
Vyatta VC4(gre/ipsec)-----Vyatta VC4-----Vyatta VC4(gre/ipsec)
If I delete the kernel route things work fine(including with dpd set to dpdaction=hold).
I can view with show vpn debug detail that transport mode is used:

src 192.168.60.2 dst 192.168.50.2
        proto esp spi 0xa8d5f97a reqid 16385 mode transport
        replay-window 32
        auth hmac(sha1) 0xbf6ccb47987ec541a84c478cbbe2889d25e03cf4
        enc cbc(aes) 0x85359fa07d406b29b610f204fd4b2f3d
        sel src 0.0.0.0/0 dst 0.0.0.0/0
src 192.168.50.2 dst 192.168.60.2
        proto esp spi 0x8c0bf82b reqid 16385 mode transport
        replay-window 32
        auth hmac(sha1) 0xd764c27216acccd461eb5311e8ba671241bca677
        enc cbc(aes) 0xda3fd7d5db625b80894cc478b02c6588
        sel src 0.0.0.0/0 dst 0.0.0.0/0
stig
Gre over IPsec

adriand wrote:
Hi Stig,
Just to let you know, I've downloaded VC4 final and tested ESP transport mode + Gre tunnels.
Vyatta VC4(gre/ipsec)-----Vyatta VC4-----Vyatta VC4(gre/ipsec)
If I delete the kernel route things work fine(including with dpd set to dpdaction=hold).
I can view with show vpn debug detail that transport mode is used:
src 192.168.60.2 dst 192.168.50.2
        proto esp spi 0xa8d5f97a reqid 16385 mode transport
        replay-window 32
        auth hmac(sha1) 0xbf6ccb47987ec541a84c478cbbe2889d25e03cf4
        enc cbc(aes) 0x85359fa07d406b29b610f204fd4b2f3d
        sel src 0.0.0.0/0 dst 0.0.0.0/0
src 192.168.50.2 dst 192.168.60.2
        proto esp spi 0x8c0bf82b reqid 16385 mode transport
        replay-window 32
        auth hmac(sha1) 0xd764c27216acccd461eb5311e8ba671241bca677
        enc cbc(aes) 0xda3fd7d5db625b80894cc478b02c6588
        sel src 0.0.0.0/0 dst 0.0.0.0/0

Great! Thanks for the confirmation Adrian

o9e
i'm a new bie please help me...

adriand why i can't ping the HQ, branch1, branch2?? i use the configuration bellow but when i commit, VPN configuration error. can not use local-subnet or remote-subnet when using transport mode and commit returns failed.

please help me,,

adriand
Gre over IPsec

Hi o9e,
I think it would be useful to tell us what are you trying to do and what you have done so far.
If you are using Vyatta VC4 with ESP in transport mode, you do not need to specify the local-subnet or remote-subnet.
Stig added a fix for that in the final VC4.
The above configs with ESP in transport mode are for Glendale Alpha or Beta where you need to manually edit ipsec.conf to make transport mode work.
With Vyatta VC4 transport mode is working from the CLI (as said before you do not need to specify the local-subnet or remote-subnet).
But you will still have to deal with the kernel routes if you plan to use transport mode.
This link might help you.
Adrian

o9e
HuPpfh great. . .

hi, adriand :D i forget both of you and stig are a PRo

hehehe... but can you teach me more about vyatta? i really interested with it, thanx 4 the link of your website adriand,,,, oh ya ican't buy the Glendale alpha or beta coz i'm just a poor student so i can't follow as you and stig do...

i hope u and stig can guide me more :lol:
thanx adriand...

stig
Re: HuPpfh great. . .

o9e wrote:
hi, adriand :D i forget both of you and stig are a PRo

hehehe... but can you teach me more about vyatta? i really interested with it, thanx 4 the link of your website adriand,,,, oh ya ican't buy the Glendale alpha or beta coz i'm just a poor student so i can't follow as you and stig do...

i hope u and stig can guide me more :lol:
thanx adriand...

Hi o9e,

You haven't really described the problem you're having. Could you provide more detail on the configuration and the specific problem?

I also highly recommend Adrian's VPN tutuorials at http://www.carbonwind.net. There's a wealth of information there and most of it can be done using the free versions of vmware server and vyatta VC4.

cesarbq
Keeping The Remote Connection

Hi Stig,

Could I keep my remote connection with a connection site-to-site working?

Regards,
Cesar

stig wrote:
adriand wrote:
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.

Great news and thanks for posting your example configurations - I'm sure they'll be very helpful to the next person who trys to inter-operate with a cisco box.

stig
Re: Keeping The Remote Connection

cesarbq wrote:
Hi Stig,

Could I keep my remote connection with a connection site-to-site working?

Regards,
Cesar

Hi Cesar,

I'm not sure I understand your question. Could you explain in more detail or what problem you're seeing?

adriand
Gre over IPsec

I don't know if someone is interested or not, but a possible fix for that kernel route and ESP in transport mode, appears to be the adding of the leftnexthop parameter within /etc/ipsec.conf for the VPN connection. And to find a way to preserve it through reboots.
Maybe is not quite elegant, but might work, as the kernel route gets modified. The downside is that, if the gw changes, that parameter needs to be changed too.

Say we have something like this:

                                192.168.50.2/24
192.168.10.0/24---VyattaVC4Left------------------
                                                 |
                                                 |
                                                 | 192.168.50.1/24
                                         VyattaVC4Center
                                                 | 192.168.60.1/24
                                                 |
                                 192.168.60.2/24 |
192.168.40.0/24---VyattaVC4Right-----------------

I've added on Vyatta VC4Left 'leftnexthop=192.168.50.1':

conn peer-192.168.60.2-tunnel-1
        left=192.168.50.2
        right=192.168.60.2
        leftnexthop=192.168.50.1
        ike=aes128-sha1-modp1536
        ikelifetime=28800s
        aggrmode=no
        esp=aes128-sha1
        keylife=3600s
        rekeymargin=540s
        type=transport
        pfs=yes
        compress=no
        authby=secret
        auto=start

I've added on Vyatta VC4Right 'leftnexthop=192.168.60.1':

conn peer-192.168.50.2-tunnel-1
        left=192.168.60.2
        right=192.168.50.2
        leftnexthop=192.168.60.1
        ike=aes128-sha1-modp1536
        ikelifetime=28800s
        aggrmode=no
        esp=aes128-sha1
        keylife=3600s
        rekeymargin=540s
        type=transport
        pfs=yes
        compress=no

Routing table on VyattaVC4Left before adding that line:

vyatta@vyattaleft:~$ 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, 01:25:20
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
O   192.168.111.0/30 [110/10] is directly connected, tun1, 01:25:15
C>* 192.168.111.0/30 is directly connected, tun1

Routing table on VyattaVC4Left after adding that line:

vyatta@vyattaleft:~$ 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, 01:59:22
C>* 192.168.10.0/24 is directly connected, eth1
O>* 192.168.40.0/24 [110/20] via 192.168.111.2, tun1, 00:05:08
C>* 192.168.50.0/24 is directly connected, eth0
K>* 192.168.60.2/32 via 192.168.50.1, eth0
O   192.168.111.0/30 [110/10] is directly connected, tun1, 01:59:17
C>* 192.168.111.0/30 is directly connected, tun1

Routing table on VyattaVC4Right before adding that line:

vyatta@vyattaright:~$ 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
C>* 127.0.0.0/8 is directly connected, lo
O   192.168.40.0/24 [110/10] is directly connected, eth1, 01:25:25
C>* 192.168.40.0/24 is directly connected, eth1
K>* 192.168.50.2/32 is directly connected, eth0
C>* 192.168.60.0/24 is directly connected, eth0
O   192.168.111.0/30 [110/10] is directly connected, tun1, 01:26:19
C>* 192.168.111.0/30 is directly connected, tun1

Routing table on VyattaVC4Right after adding that line:

vyatta@vyattaright:~$ 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
C>* 127.0.0.0/8 is directly connected, lo
O>* 192.168.10.0/24 [110/20] via 192.168.111.1, tun1, 00:05:13
O   192.168.40.0/24 [110/10] is directly connected, eth1, 01:58:26
C>* 192.168.40.0/24 is directly connected, eth1
K>* 192.168.50.2/32 via 192.168.60.1, eth0
C>* 192.168.60.0/24 is directly connected, eth0
O   192.168.111.0/30 [110/10] is directly connected, tun1, 01:59:20
C>* 192.168.111.0/30 is directly connected, tun1

On the VyattaVC4Left I've configured:

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

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 Right"
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 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 esp-group ESP-GRE
top 

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 log-adjacency-changes
commit

On the VyattaVC4Right I've configured:

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

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 Left"
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 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 esp-group ESP-GRE
top

set protocols ospf area 100
set protocols ospf area 100 network 192.168.40.0/24
set protocols ospf area 100 network 192.168.111.0/30
set protocols ospf log-adjacency-changes
commit 

On the VyattaVC4Center I've configured:

set interfaces ethernet eth0 address 192.168.50.1/24
set interfaces ethernet eth1 address 192.168.60.1/24
stig
Gre over IPsec

Hi adriand,

Haven't see you on the board lately - good to have you back.

I still have it on my todo list to looking into the kernel route thing. Your suggested workaround seems like it would work, but it would be even better if that kernel interface route never got added.

I had one other user mention this issue and his work around was to edit /opt/vyatta/share/vyatta-cfg/vpn/node.def and add a call to linux to removed the specific kernel route after the call to vpn-config.pl in that file. That certainly isn't a viable general purpose workaround, but it is a quick & dirty hack that has been working for him.

I do have a few ideas for a real fix, just haven't had the time yet. :-(

adriand
Gre over IPsec

Hi Stig,
Yes, it's been a while.
By the way, I got working IPsec in transport mode with the Cisco router as some may attempt to configure on the Cisco side.
Say I take out the VyattaVC4Right and replace it with a Cisco router(an old 3640 12.3(14)).
Add on the Cisco router the crypto ACL like(saying only GRE traffic to be protected by IPsec, what we want):
access-list 101 permit 47 host 192.168.60.2 host 192.168.50.2
On VyattaVC4Left I would add the following lines to the already modified as above ipsec.conf(OK, these will not be preserved through a reboot):
leftprotoport=gre
rightprotoport=gre
So I end up with:

conn peer-192.168.60.2-tunnel-1
        left=192.168.50.2
        right=192.168.60.2
        leftnexthop=192.168.50.1
        leftprotoport=gre
        rightprotoport=gre
        ike=aes128-sha1-modp1536
        ikelifetime=28800s
        aggrmode=no
        esp=aes128-sha1
        keylife=3600s
        rekeymargin=540s
        type=transport
        pfs=yes
        compress=no
        authby=secret
        auto=start

Now the Cisco router looks happy:

*Mar  1 00:13:14.603: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 192.168.60.2, remote= 192.168.50.2,
    local_proxy= 192.168.60.2/255.255.255.255/47/0 (type=1),
    remote_proxy= 192.168.50.2/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-aes esp-sha-hmac  (Transport)

interface: FastEthernet0/0
    Crypto map tag: GRE, local addr 192.168.60.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.60.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.50.2/255.255.255.255/47/0)
   current_peer 192.168.50.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 374, #pkts encrypt: 374, #pkts digest: 374
    #pkts decaps: 378, #pkts decrypt: 378, #pkts verify: 378
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 192.168.60.2, remote crypto endpt.: 192.168.50.2
     path mtu 1500, ip mtu 1500
     current outbound spi: 0xE53AB05B(3845828699)

     inbound esp sas:
      spi: 0xA24C0D7E(2722893182)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Transport, }
        conn id: 2004, flow_id: SW:4, crypto map: GRE
        sa timing: remaining key lifetime (k/sec): (4454990/2008)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

On Vyatta:

src 192.168.60.2/32 dst 192.168.50.2/32 proto gre
        dir in priority 2080 ptype main
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16385 mode transport
src 192.168.50.2/32 dst 192.168.60.2/32 proto gre
        dir out priority 2080 ptype main
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto esp reqid 16385 mode transport

Now if I ping from VyattaVC4Left to the Cisco router using the "public" IP addresses as source and destination, this traffic is no more protected by IPsec(no need for that), a more resource saving method, sort of.

steve.dutky
registered addresses?

In this example, the tunnels and loopbacks all have registered addresses, while the eth0,eth1 have private addresses.

In real life would all addresses need to route over the internet?

Many thanks.

stig wrote:
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.

     +----------+                                    +----------+
     |          |                                    |          |
 eth0|          |eth1                            eth0|          |eth1
-----+ router-A +-------------  INTERNET ------------+ router-B +-----
     |          |                                    |          |
     |          |                                    |          |
     +----+-----+                                    +----+-----+
          |                                               |
          |lo0                                            |lo0

  

router-A
========

interfaces {
    ethernet eth0 {
        address "172.16.117.128/24"
        hw-id: 00:0c:29:b0:1d:bb
    }
    ethernet eth1 {
        address "192.168.249.128/24"
        hw-id: 00:0c:29:b0:1d:d9
    }
    loopback lo {
        address "9.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
    }
}
protocols {
    ospf {
        area 0 {
            network 172.16.117.0/24
            network 7.0.0.0/24
        }
        log-adjacency-changes {
        }
        parameters {
            router-id: 9.0.0.1
        }
        redistribute {
            connected {
            }
        }
    }
    static {
        route 172.16.139.0/24 {
            next-hop 192.168.249.150 {
            }
        }
    }
}
vpn {
    ipsec {
        esp-group foo {
            proposal 1 {
            }
        }
        ike-group foo {
            proposal 1 {
            }
        }
        ipsec-interfaces {
            interface "eth1"
        }
        logging {
            facility: daemon
            level: info
        }
        site-to-site {
            peer 172.16.139.160 {
                authentication {
                    pre-shared-secret: "testing123"
                }
                ike-group: "foo"
                local-ip: 192.168.249.128
                tunnel 1 {
                    esp-group: "foo"
                    local-subnet: 9.0.0.0/24
                    remote-subnet: 11.0.0.0/24
                }
            }
        }
    }
}





router-B
========

interfaces {
    ethernet eth0 {
        address "172.16.139.160/24"
        hw-id: 00:0c:29:df:17:97
    }
    ethernet eth1 {
        address "192.168.74.160/24"
        hw-id: 00:0c:29:df:17:a1
    }
    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
    }
}
protocols {
    ospf {
        area 0 {
            network 192.168.74.0/24
            network 7.0.0.0/24
        }
        log-adjacency-changes {
        }
        parameters {
            router-id: 11.0.0.1
        }
        redistribute {
            connected {
            }
        }
    }
    static {
        route 192.168.249.0/24 {
            next-hop 172.16.139.150 {
            }
        }
    }
}
vpn {
    ipsec {
        esp-group foo {
            proposal 1 {
            }
        }
        ike-group foo {
            proposal 1 {
            }
        }
        ipsec-interfaces {
            interface "eth0"
        }
        site-to-site {
            peer 192.168.249.128 {
                authentication {
                    pre-shared-secret: "testing123"
                }
                ike-group: "foo"
                local-ip: 172.16.139.160
                tunnel 1 {
                    esp-group: "foo"
                    local-subnet: 11.0.0.0/24
                    remote-subnet: 9.0.0.0/24
                }
            }
        }
    }
}
adriand
Gre over IPsec

Actually the IP addresses from that example have no meaning.

In a real world example, only the IP addresses from the eth1 of left Vyatta and eth0 of right Vyatta need to be public IP addresses.
IPsec tunnel mode is used, so IPsec ESP provides tunneling, encapsulating the entire packet(including the IP header), and adding a new IP header with the IP addresses from the above mentioned interfaces as source and destination.
You can take a look at this picture to see how an IP packet looks after it has leaved the external interface(note that the IP addresses do not correspond to the one from Stig's example).

Adrian

Cheeze
Gre over IPsec

I know I am resurrecting this thread....but how does one remove the kernel route...

That is something I just do not know about...

Also, is it possible to add that option as default behavior in Openswan within the Vyatta system?

Or if that's not doable then like say under the "peer x.x.x.x" add another group called "parameter" and add a command like "set remove-kernel-route enable"

I'm trying to get this to work and I can't....mainly because I don't know where to go to remove the kernel route...

----------------------------------------EDIT-------------------------------------

Ok, I did some digging and I feel like an idiot. It seems that to delete the Kernel route all one has to do is type: "sudo ip route delete "

That's fine and dandy really, however Stig, is it possible that it can be added to where I don't have to manually delete the route on the outside? Or get it to where the Kernel route never gets entered?. It seems that the code could be really easy to actually implement....not that I'm a coder but as I said earlier up top one could just add the option to disable the kernel route and when that option is enabled in the config then the " sudo ip route delete " can be used to delete the route.

Sorry if I'm not making much sense....just trying to help...