Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

FAQ
It is currently Sat Aug 19, 2017 2:44 am


Author Message
mandrei99
Post  Post subject: Linux site to site GRE over IPSEC VPN tunnels using racoon & kame ipsec-tools  |  Posted: Tue Jan 13, 2015 6:26 am

Joined: Tue Aug 04, 2009 9:16 am
Posts: 245

Offline
 

Linux site to site GRE over IPSEC VPN tunnels using racoon & kame ipsec-tools

Before reading my article, the reader needs to get familiarized with ipsec concepts. Here is a good starting point: IPSEC Illustrated http://www.unixwiz.net/techtips/iguide-ipsec.html

Securing communication over public internet between two Linux endpoints can be performed in multiple ways via encryption at layer 3 or at layer 4/7. I'm using IPSEC wherever it is possible. This is layer 3/4 encryption (if NAT-T is performed).

With IPSEC there are two modes for phase 2 encapsulation: transport mode and tunnel mode. Transport mode encrypts only layer 4 data (above IP header - ip payload) and tunnel mode encrypts layer 3 data - it encrypts the whole IP packet.
Differences, advantages and disadvantages are obvious. Here are some of them:
- higher overhead for tunnel mode as it has to encrypt extra IP header.
- tunnel mode can connect lan to lan whereas transport mode can connect only host to host through encrypted tunnel.
- tunnel mode in some ipsec implementations does not support carrying of multicast IP packets, thus GRE tunnel inside ipsec tunnel or transport mode is used.

In this example, I'm setting up a transport mode ipsec tunnel between two Linux servers, but with GRE tunnel configured. The linux security policy database contains entries that instruct both Linux ipsec endpoints to encrypt GRE traffic between the two nodes.
Some vendors (Cisco and Juniper) refer to the security policy database as proxy identifiers. Linux and FreeBSD refer to these as plain Security Policy Database - SPD. The security policy database / proxy IDs define contain filters that define what packets are being encapsulated and encrypted in the IPSEC tunnel (for ESP mode).

Thus, with ipsec transport mode and security policies / proxy IDs defining that GRE traffic between the ipsec endpoints, it is possible to connect two sites (lan to lan). How does it work ?

1. Packet from a host on lan1 is forwarded to local ipsec endpoint ( next-hop for the destination of host in lan2).
2. Local ipsec endpoint has a route to the host on lan2 via GRE tunnel towards remote ipsec endpoint. It queues the packet in GRE tunnel.
3. Local ipsec endpoint also checks the security policy database and finds an an entry (proxy id) stating that gre traffic to remote ipsec endpoint should be encrypted in ipsec transport mode.
4. Local ipsec endpoint encrypts the payload towards remote endpoint. That encrypted payload contains gre header, original IP header with source of local lan1 host and remote lan2 host.
-- On the receiving side --
1. The remote ipsec endpoint receives an encrypted packet from local ipsec endpoint.
2. Remote ipsec endpoint checks it's security policy database and finds an entry for incoming encrypted traffic from the local ipsec endpoint ip address.
3. Remote ipsec endpoint decrypts the the packet according to the security association matched on the SPI value inside the ESP header.
4. After decryption, remote ipsec endpoint decapsulates the packet in the GRE tunnel and routes the original IP to lan2 host (destination ip address in original ip header).

Linux network and ipsec configuration - ipsec endpoint 1:
Linux network config.
Code:
# ip a l eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 5a:b4:f6:a4:f4:b6 brd ff:ff:ff:ff:ff:ff
    inet 1.1.1.1/24 brd 162.220.52.255 scope global eth0
    inet6 fe80::58b4:f6ff:fea4:f4b6/64 scope link
       valid_lft forever preferred_lft forever
# ip a l tun0
5: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN
    link/gre 1.1.1.1 peer 2.2.2.2
    inet 10.1.1.1 peer 10.1.1.2/32 scope global tun0


Linux ipsec configuration - security policy database / proxy IDs
Code:
# cat /etc/racoon/setkey.conf
flush;
spdflush;


spdadd 1.1.1.1/32[0] 2.2.2.2/32[0] gre -P out ipsec esp/transport//require;
spdadd 2.2.2.2/32[0] 1.1.1.1/32[0] gre -P in ipsec esp/transport//require;

# setkey -DP
1.1.1.1 2.2.2.2 gre
        out prio def ipsec
        esp/transport//require
        created: Jan 12 21:43:16 2015  lastused: Jan 13 04:07:40 2015
        lifetime: 86400(s) validtime: 0(s)
        spid=377 seq=1 pid=21300
        refcnt=3
2.2.2.2 1.1.1.1 gre
        in prio def ipsec
        esp/transport//require
        created: Jan 12 21:43:16 2015  lastused: Jan 13 04:07:45 2015
        lifetime: 86400(s) validtime: 0(s)
        spid=368 seq=2 pid=21300
        refcnt=3

Linux ipsec configuration - phase 1 configuration and proposal, phase 2 proposal (quick mode).
Code:
# cat /etc/racoon/racoon.conf
...
remote 2.2.2.2{
        exchange_mode main;
        initial_contact on;

        dpd_delay 20;
        dpd_retry 2;
        dpd_maxfail 2;
        rekey on;
        verify_identifier off;
        my_identifier address 1.1.1.1;
        peers_identifier address 2.2.2.2;
        lifetime time 24 hours;
        proposal {
           encryption_algorithm aes;
           hash_algorithm sha1;
           authentication_method pre_shared_key;
           dh_group 2;
      }
}
sainfo anonymous
{
   pfs_group 2;
   encryption_algorithm aes ;
   authentication_algorithm hmac_sha1;
   lifetime time 86400 seconds;
   compression_algorithm deflate ;
}


The "remote" racoon configuration snippet defines phase 1 parameters. I will quote racoon.conf manual:
Quote:
initial_contact (on | off);
Enable this to send an INITIAL-CONTACT message. The default value is on. This message is useful only when the responder implementa-
tion chooses an old SA when there are multiple SAs with different established time and the initiator reboots. If racoon did not send
the message, the responder would use an old SA even when a new SA was established. For systems that use a KAME derived IPSEC stack,
the sysctl(8) variable net.key.preferred_oldsa can be used to control this preference. When the value is zero, the stack always uses
a new SA.
...
rekey (on | off | force);
Enable automatic renegotiation of expired phase1 when there are non-dying phase2 SAs. Possible values are:
force Rekeying is done unconditionally.
on Rekeying is done only if DPD monitoring is active. This is the default.
off No automatic rekeying. Do note that turning off automatic rekeying will result in inaccurate DPD monitoring.
...

If the racoon.conf manual explanation of the "initial_contact" ipsec message, here is a quote from RFC5996 for ikev2 explains a little more:
Quote:
The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA currently active between the authenticated identities. It MAY
be sent when an IKE SA is established after a crash, and the
recipient MAY use this information to delete any other IKE SAs it has
to the same authenticated identity without waiting for a timeout.
This notification MUST NOT be sent by an entity that may be
replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems
at the same time). The INITIAL_CONTACT notification, if sent, MUST
be in the first IKE_AUTH request or response, not as a separate
exchange afterwards; receiving parties MAY ignore it in other
messages.

Since IKE is designed to operate in spite of DoS attacks from the
network, an endpoint MUST NOT conclude that the other endpoint has
failed based on any routing information (e.g., ICMP messages) or IKE
messages that arrive without cryptographic protection (e.g., Notify
messages complaining about unknown SPIs). An endpoint MUST conclude
that the other endpoint has failed only when repeated attempts to
contact it have gone unanswered for a timeout period or when a
cryptographically protected INITIAL_CONTACT notification is received
on a different IKE SA to the same authenticated identity. An
endpoint should suspect that the other endpoint has failed based on
routing information and initiate a request to see whether the other
endpoint is alive. To check whether the other side is alive, IKE
specifies an empty INFORMATIONAL message that (like all IKE requests)
requires an acknowledgement (note that within the context of an IKE
SA, an "empty" message consists of an IKE header followed by an
Encrypted payload that contains no payloads). If a cryptographically
protected (fresh, i.e., not retransmitted) message has been received
from the other side recently, unprotected Notify messages MAY be
ignored. Implementations MUST limit the rate at which they take
actions based on unprotected messages.


The "sainfo" racoon configuration snippet defines phase2 (quick-mode) proposal.
Configuration for remote ipsec endpoint is symmetrical.

How does this work ? Local endpoint runs a GRE tunnel with remote ipsec endpoint. GRE tunnel local IP is 10.1.1.1 and remote IP 10.1.1.2.

Security policy database for outgoing/incoming GRE traffic:
Code:
# setkey -DP
1.1.1.1 2.2.2.2 gre
        out prio def ipsec
        esp/transport//require
        created: Jan 12 21:43:16 2015  lastused: Jan 13 04:07:40 2015
        lifetime: 86400(s) validtime: 0(s)
        spid=377 seq=1 pid=21300
        refcnt=3
2.2.2.2 1.1.1.1 gre
        in prio def ipsec
        esp/transport//require
        created: Jan 12 21:43:16 2015  lastused: Jan 13 04:07:45 2015
        lifetime: 86400(s) validtime: 0(s)
        spid=368 seq=2 pid=21300
        refcnt=3

Dumping ipsec phase 2 security associations using setkey:
Code:
# setkey -D
1.1.1.1 2.2.2.2
        esp mode=transport spi=94953994(0x05a8e20a) reqid=0(0x00000000)
        E: aes-cbc  b397f602 9caadb49 77ea76e4 a6a81e87
        A: hmac-sha1  9891f0f2 d4d06f94 144522fe d25a9c28 98df40c2
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Jan 12 21:43:16 2015   current: Jan 13 04:56:41 2015
        diff: 26005(s)  hard: 86400(s)  soft: 69120(s)
        last: Jan 12 21:43:19 2015      hard: 0(s)      soft: 0(s)
        current: 192520(bytes)  hard: 0(bytes)  soft: 0(bytes)
        allocated: 2643 hard: 0 soft: 0
        sadb_seq=1 pid=21309 refcnt=0
2.2.2.2 1.1.1.1
        esp mode=transport spi=44094341(0x02a0d385) reqid=0(0x00000000)
        E: aes-cbc  ef558e0a c133e3be b5453910 77f9564f
        A: hmac-sha1  3afcb4e9 580b181d b0f21c0f fe114037 b3f9e2b4
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Jan 12 21:43:16 2015   current: Jan 13 04:56:41 2015
        diff: 26005(s)  hard: 86400(s)  soft: 69120(s)
        last: Jan 12 21:43:24 2015      hard: 0(s)      soft: 0(s)
        current: 192296(bytes)  hard: 0(bytes)  soft: 0(bytes)
        allocated: 2642 hard: 0 soft: 0
        sadb_seq=0 pid=21309 refcnt=0

For interested parties, it is possible to dump ipsec phase 2 security associations using "racoonctl" tool also:
Code:
# racoonctl -ll ss esp
1.1.1.1 2.2.2.2
        esp mode=transport spi=94953994(0x05a8e20a) reqid=0(0x00000000)
        E: aes-cbc  b397f602 9caadb49 77ea76e4 a6a81e87
        A: hmac-sha1  9891f0f2 d4d06f94 144522fe d25a9c28 98df40c2
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Jan 12 21:43:16 2015   current: Jan 13 05:05:08 2015
        diff: 26512(s)  hard: 86400(s)  soft: 69120(s)
        last: Jan 12 21:43:19 2015      hard: 0(s)      soft: 0(s)
        current: 196648(bytes)  hard: 0(bytes)  soft: 0(bytes)
        allocated: 2698 hard: 0 soft: 0
        sadb_seq=1 pid=1401 refcnt=0
2.2.2.2 1.1.1.1
        esp mode=transport spi=44094341(0x02a0d385) reqid=0(0x00000000)
        E: aes-cbc  ef558e0a c133e3be b5453910 77f9564f
        A: hmac-sha1  3afcb4e9 580b181d b0f21c0f fe114037 b3f9e2b4
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Jan 12 21:43:16 2015   current: Jan 13 05:05:08 2015
        diff: 26512(s)  hard: 86400(s)  soft: 69120(s)
        last: Jan 12 21:43:24 2015      hard: 0(s)      soft: 0(s)
        current: 196508(bytes)  hard: 0(bytes)  soft: 0(bytes)
        allocated: 2698 hard: 0 soft: 0
        sadb_seq=0 pid=1401 refcnt=0


Capturing ipsec esp traffic in tcpdump:
Code:
# tcpdump -nni eth0 host 2.2.2.2 and esp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
04:57:50.660853 IP 1.1.1.1 > 2.2.2.2: ESP(spi=0x05a8e20a,seq=0xa5a), length 116
04:57:54.815240 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x02a0d385,seq=0xa5a), length 132


Local endpoint, according to the security policy database, encrypts GRE tunnel to the remote endpoint using established ipsec security associations for the authenticated remote endpoint. The ESP header for the encrypted traffic contains the SPI (security policy index) 0x05a8e20a.
For incoming, local endpoint is matching incoming ESP traffic (SPI 0x02a0d385) to the security association spi=44094341(0x02a0d385).
How to verify racoon ipsec ike phase 1 is established:
Code:
# racoonctl -ll ss isakmp
Source                                        Destination                                   Cookies                           ST S  V E Created             Phase2
1.1.1.1.500                             2.2.2.2.500                            a3e1b8ebf4926cc6:0cc6ac95c4f8141e  9 R 10 M 2015-01-12 21:43:15      1


To read more info about the security policy database for racoon/ipsec-tools, the manual for "setkey" utility helps. Quote:
Quote:
...
flush [protocol] ;
Clear all SAD entries matched by the options. -F on the command line achieves the same functionality.
...
spdflush ;
Clear all SPD entries. -FP on the command line achieves the same functionality.
...
spdadd [-46n] src_range dst_range upperspec label policy ;
Add an SPD entry.

spdadd tagged tag policy ;
Add an SPD entry based on a PF tag. tag must be a string surrounded by double quotes.
...
src_range
dst_range
These select the communications that should be secured by IPsec. They can be an IPv4/v6 address or an IPv4/v6 address range, and may be
accompanied by a TCP/UDP port specification. This takes the following form:

address
address/prefixlen
address[port]
address/prefixlen[port]

prefixlen and port must be decimal numbers. The square brackets around port are really necessary, they are not man page meta-characters.
For FQDN resolution, the rules applicable to src and dst apply here as well.
...
upperspec
Upper-layer protocol to be used. You can use one of the words in /etc/protocols as upperspec, or icmp6, ip4, gre, or any. any stands for
“any protocol”. You can also use the protocol number. Additional specification can be placed after the protocol name for some protocols.
You can specify a type and/or a code of ICMP or ICMPv6. The type is separated from a code by single comma and the code must always be speci-
fied. GRE key can be specified in dotted-quad format or as plain number. When a zero is specified, the kernel deals with it as a wildcard.
Note that the kernel can not distinguish a wildcard from an ICPMv6 type of zero.

For example, the following means that the policy doesn’t require IPsec for any inbound Neighbor Solicitation.
spdadd ::/0 ::/0 icmp6 135,0 -P in none;

A second example of requiring transport mode encryption of specific GRE tunnel:
spdadd 0.0.0.0 0.0.0.0 gre 1234 ipsec esp/transport//require;

Note: upperspec does not work against forwarding case at this moment, as it requires extra reassembly at the forwarding node (not implemented
at this moment). There are many protocols in /etc/protocols, but all protocols except of TCP, UDP, GRE, and ICMP may not be suitable to use
with IPsec. You have to consider carefully what to use.
...
policy policy is in one of the following three formats:
-P direction [priority specification] discard
-P direction [priority specification] none
-P direction [priority specification] ipsec protocol/mode/src-dst/level [...]

You must specify the direction of its policy as direction. Either out, in, or fwd can be used.

priority specification is used to control the placement of the policy within the SPD. Policy position is determined by a signed integer
where higher priorities indicate the policy is placed closer to the beginning of the list and lower priorities indicate the policy is placed
closer to the end of the list. Policies with equal priorities are added at the end of groups of such policies.

Priority can only be specified when setkey has been compiled against kernel headers that support policy priorities (Linux >= 2.6.6). If the
kernel does not support priorities, a warning message will be printed the first time a priority specification is used. Policy priority takes
one of the following formats:

{priority,prio} offset
offset is an integer in the range from -2147483647 to 214783648.

{priority,prio} base {+,-} offset
base is either low (-1073741824), def (0), or high (1073741824)

offset is an unsigned integer. It can be up to 1073741824 for positive offsets, and up to 1073741823 for negative offsets.

discard means the packet matching indexes will be discarded. none means that IPsec operation will not take place onto the packet. ipsec
means that IPsec operation will take place onto the packet.

The protocol/mode/src-dst/level part specifies the rule how to process the packet. Either ah, esp, or ipcomp must be used as protocol. mode
is either transport or tunnel. If mode is tunnel, you must specify the end-point addresses of the SA as src and dst with ‘-’ between these
addresses, which is used to specify the SA to use. If mode is transport, both src and dst can be omitted. level is to be one of the follow-
ing: default, use, require, or unique. If the SA is not available in every level, the kernel will ask the key exchange daemon to establish a
suitable SA. default means the kernel consults the system wide default for the protocol you specified, e.g. the esp_trans_deflev sysctl
variable, when the kernel processes the packet. use means that the kernel uses an SA if it’s available, otherwise the kernel keeps normal
operation. require means SA is required whenever the kernel sends a packet matched with the policy. unique is the same as require; in addi-
tion, it allows the policy to match the unique out-bound SA. You just specify the policy level unique, racoon(8) will configure the SA for
the policy. If you configure the SA by manual keying for that policy, you can put a decimal number as the policy identifier after unique
separated by a colon ‘:’ like: unique:number in order to bind this policy to the SA. number must be between 1 and 32767. It corresponds to
extensions -u of the manual SA configuration. When you want to use SA bundle, you can define multiple rules. For example, if an IP header
was followed by an AH header followed by an ESP header followed by an upper layer protocol header, the rule would be:
esp/transport//require ah/transport//require;
The rule order is very important.

When NAT-T is enabled in the kernel, policy matching for ESP over UDP packets may be done on endpoint addresses and port (this depends on the
system. System that do not perform the port check cannot support multiple endpoints behind the same NAT). When using ESP over UDP, you can
specify port numbers in the endpoint addresses to get the correct matching. Here is an example:

spdadd 10.0.11.0/24[any] 10.0.11.33/32[any] any -P out ipsec
esp/tunnel/192.168.0.1[4500]-192.168.1.2[30000]/require ;

These ports must be left unspecified (which defaults to 0) for anything other than ESP over UDP. They can be displayed in SPD dump using
setkey -DPp.

Note that “discard” and “none” are not in the syntax described in ipsec_set_policy(3). There are a few differences in the syntax. See
ipsec_set_policy(3) for detail.
...



Acronyms:
SPD - Security Policy Database
SAD - Security Associations Database (phase2).

Even though ipsec transport mode is used but because GRE tunnel is the external IP payload, the two linux ipsec endpoints act as gateways and they can forward traffic between the two LANs and they can also carry multicast traffic (run OSPF / quagga).
Notes:
- The "policy" term in setkey manual is the actual security policy entry in the SPD.
- I tested and the src_range and dst_range entries for the security policy database require to be defined as IP/32[0] (meaning port 0) not as IP or IP/32, for GRE traffic to match the security policy. It did not work until this change.





Top
Display posts from previous:  Sort by  
E-mail friendPrint view

Topics related to - "Linux site to site GRE over IPSEC VPN tunnels using racoon & kame ipsec-tools"
 Topics   Author   Replies   Views   Last post 
There are no new unread posts for this topic. Juniper SRX Hub-and-Spoke IPSEC VPN \w HUB behind NAT.

mandrei99

0

1231

Tue Oct 29, 2013 11:25 am

mandrei99 View the latest post

There are no new unread posts for this topic. Site2Site Ipsec/Dialup/ike v2

balzac123

0

584

Wed Sep 16, 2015 9:07 am

balzac123 View the latest post

There are no new unread posts for this topic. Juniper SRX MTU / MSS / Fragmentation problems with Ipsec vpn tunnel

debuser

2

16254

Mon Jul 08, 2013 5:54 am

Tears View the latest post

There are no new unread posts for this topic. OpenSSL CA signed certificates based Ipsec VPN between Two Juniper SRX devices

debuser

2

6563

Thu Jun 27, 2013 10:40 am

mandrei99 View the latest post

There are no new unread posts for this topic. Iphone/Ipad Ipsec VPNs using SSL certificates - How to use OpenSSL to generate and format certs

mandrei99

0

2811

Wed Apr 10, 2013 5:42 am

mandrei99 View the latest post

There are no new unread posts for this topic. Juniper SRX 11.4: Bypass IPSEC VPN IKE ID validation for "remote-identity"

mandrei99

0

1925

Thu Oct 31, 2013 5:00 am

mandrei99 View the latest post

There are no new unread posts for this topic. Attachment(s) Juniper SRX Spoke-to-Spoke IPSEC VPN \w spokes behind NAT.

mandrei99

0

1972

Tue Oct 29, 2013 9:22 am

mandrei99 View the latest post

 

Who is online
Users browsing this forum: No registered users and 0 guests
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
Jump to:  
News News Site map Site map SitemapIndex SitemapIndex RSS Feed RSS Feed Channel list Channel list


Delete all board cookies | The team | All times are UTC - 5 hours [ DST ]



phpBB SEO