...making Linux just a little more fun!
[ In reference to "Digging More Secure Tunnels with IPsec" in LG#126 ]
Tim Chappell [tchappe1 at timchappell.plus.com]
Hi,
Having read your ipsec articles (125/126) I've been attempting to get a similar system going. I wonder if you can help? I'm trying to setup an ipsec VPN (tunnel mode) between two networks which are both behind DSL routers. I've managed to get it going successfully without the modems, but once they're in place it doesn't appear to work. Is such a thing possible? The modems both have ports 500/4500 open to allow NAT-T through (and AH/ESP passthrough).
Here's a rough outline:
# IPSEC TUNNEL
# .......................................................
# : :
# : :
# : INTERNET :
# +----------+ ---- +----------+
# | local | IP1+-------+ EIP1/ \ EIP2+-------+ IP2| remote |
# | server |----|-Modem-|----| |----|-Modem-|----| server |
# | | +-------+ \ / +-------+ | |
# +---+------+ ---- +---+------+
# | |
# | 192.168.103.0/24 | 192.168.100.0/24
# | +--------------+ | +--------------+
# | | local client |-+ | | remote client|-+
# +----+ pool | | +----+ pool | |
# +--------------+ | +--------------+ |
# +--------------+ +---------------+
Strategic parts of racoon.conf
listen
{
isakmp IP1 ;
isakmp_natt IP1 [4500];
adminsock "/var/run/racoon/racoon.sock" "root" "users" 660;
}
timer
{
natt_keepalive 10sec ;
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 20 sec; # maximum interval to resend.
persend 1; # the number of packets per a send.
# timer for waiting to complete each phase.
phase1 30 sec;
phase2 15 sec;
}
remote EIP2 [500]
{
exchange_mode main;
nat_traversal on ;
certificate_type x509 "vpnserver_cert.pem" "vpnserver_key.txt" ;
# can't set this on because racoon attempts to verify with root ca
verify_cert off;
my_identifier asn1dn;
peers_identifier asn1dn;
verify_identifier on;
proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method rsasig ;
dh_group modp1024;
}
}
## local pool (192.168.103.0/24) and remote pool (192.168.100.0/24)
sainfo address 192.168.103.0/24 any address 192.168.100.0/24 any
{
pfs_group modp768;
lifetime time 10 minutes ;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
From the two servers' perspectives it appears that you should define the
tunnel endpoints in setkey.conf as IP1-EIP2 and IP2-EIP1 (IP1 and IP2 are
unique internal 192.168.x.254 addresses and the default route on each server
is the IP address of the DSL router) and (EIP1 and EIP2 are two different
external static IP addresses):
E.g. (only one shown to save the typing):
spdadd 192.168.103.0/24 192.168.100.0/24 any -P out ipsec esp/tunnel/IP1-EIP2/require Ah/tunnel/IP1-EIP2/require;The server at the other end is setup with reversed addresses, etc. as required. As I say this worked without the DSL routers.
Excerpt from racoon.log:
Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=128): 0.000026 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=145): 0.000007 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=161): 0.000007 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=161): 0.000007 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=1): 0.000007 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=16): 0.000006 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=500): 0.000008 Jan 8 08:30:53 server racoon: alg_oakley_encdef_encrypt(3des klen=192 size=1160): 0.000109 Jan 8 08:30:53 server racoon: phase1(ident I msg3): 0.013579 Jan 8 08:30:53 server racoon: alg_oakley_encdef_decrypt(3des klen=192 size=1080): 0.000085 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=475): 0.000009 Jan 8 08:30:53 server racoon: oakley_validate_auth(RSA signatures): 0.000292 Jan 8 08:30:53 server racoon: phase1(ident R msg3): 0.000807 Jan 8 08:30:53 server racoon: phase1(Identity Protection): 0.230708 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=32): 0.000007 Jan 8 08:30:53 server racoon: alg_oakley_encdef_encrypt(3des klen=192 size=56): 0.000011 Jan 8 08:30:53 server racoon: INFO: ISAKMP-SA established IP1[4500]-EIP2[4500] spi:4d8718e1f5de6 2ad:be6f6325dd03507c Jan 8 08:30:53 server racoon: alg_oakley_encdef_decrypt(3des klen=192 size=56): 0.000010 Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=32): 0.000013 Jan 8 08:30:54 server racoon: INFO: initiate new phase 2 negotiation: IP1[4500]<=>EIP2[4500] Jan 8 08:30:54 server racoon: INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->3). Jan 8 08:30:54 server racoon: INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->3). Jan 8 08:30:54 server racoon: oakley_dh_generate(MODP768): 0.003996 Jan 8 08:30:54 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=244): 0.000009 Jan 8 08:30:54 server racoon: alg_oakley_encdef_encrypt(3des klen=192 size=264): 0.000029 Jan 8 08:30:54 server racoon: phase2(quick I msg1): 0.004238 Jan 8 08:31:09 server racoon: ERROR: EIP2 give up to get IPsec-SA due to time up to wait.Any pointers or is this just not feasible with NAT at both ends?
Thanks,
Tim.
René Pfeiffer [lynx at luchs.at]
Hello, Tim!
On Jan 09, 2008 at 2040 -0000, Tim Chappell appeared and said:
> [...] > I wonder if you can help?=20
Me too. ;-)
> I'm trying to setup an ipsec VPN (tunnel mode) between two networks > which are both behind DSL routers. I've managed to get it going > successfully without the modems, but once they're in place it doesn't > appear to work. Is such a thing possible?
In theory it is possible, but there are some important details that have to be checked.
> The modems both have ports 500/4500 open to allow NAT-T through (and > AH/ESP passthrough).
Do you know what kinds of modems you use? Some modems/routers have bugs in their firmware that make setups such as yours unusable. Another thing to check is the "ports 500/4500 open" configuration. In order for key exchange to work the ports must stay the same for 500/UDP and 4500/UDP (both source and destination). If any intermediate NAT device uses port pools and changes either port the key exchange will fail.
> Here's a rough outline: > [...]
The diagram got a bit broken due to wrapping, but thanks! That's great for understanding your setup.
> Strategic parts of racoon.conf
> listen
> {
> isakmp IP1 ;
> isakmp_natt IP1 [4500];
> adminsock "/var/run/racoon/racoon.sock" "root" "users" 660;
> }
> timer
> {
> natt_keepalive 10sec ;
> # These value can be changed per remote node.
> counter 5; # maximum trying count to send.
> interval 20 sec; # maximum interval to resend.
> persend 1; # the number of packets per a send.
> # timer for waiting to complete each phase.
> phase1 30 sec;
> phase2 15 sec;
> }
> remote EIP2 [500]
> {
> exchange_mode main;
> nat_traversal on ;
Looks ok so far. Does "nat_traversal force;" make a difference?
> certificate_type x509 "vpnserver_cert.pem" "vpnserver_key.txt" ; > # can't set this on because racoon attempts to verify with root ca > verify_cert off;
How did you create the certificates?
> [...] > From the two servers' perspectives it appears that you should define the > tunnel endpoints in setkey.conf as IP1-EIP2 and IP2-EIP1 (IP1 and IP2 are > unique internal 192.168.x.254 addresses and the default route on each server > is the IP address of the DSL router) and (EIP1 and EIP2 are two different > external static IP addresses): > E.g. (only one shown to save the typing): > spdadd 192.168.103.0/24 192.168.100.0/24 any -P out ipsec > esp/tunnel/IP1-EIP2/require > Ah/tunnel/IP1-EIP2/require;
Looks ok, too.
> The server at the other end is setup with reversed addresses, etc. as > required. As I say this worked without the DSL routers.
I smell the conspiracy of fiendish firmware at work.
> Excerpt from racoon.log: > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D128): > 0.000026 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D145): > 0.000007 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D161): > 0.000007 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D161): > 0.000007 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D1): > 0.000007 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D16): > 0.000006 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D500): > 0.000008 > Jan 8 08:30:53 server racoon: alg_oakley_encdef_encrypt(3des klen=3D192 > size=3D1160): 0.000109 > Jan 8 08:30:53 server racoon: phase1(ident I msg3): 0.013579 > Jan 8 08:30:53 server racoon: alg_oakley_encdef_decrypt(3des klen=3D192 > size=3D1080): 0.000085 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D475=): > 0.000009 > Jan 8 08:30:53 server racoon: oakley_validate_auth(RSA signatures): > 0.000292 > Jan 8 08:30:53 server racoon: phase1(ident R msg3): 0.000807 > Jan 8 08:30:53 server racoon: phase1(Identity Protection): 0.230708 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D32): > 0.000007 > Jan 8 08:30:53 server racoon: alg_oakley_encdef_encrypt(3des klen=3D192 > size=3D56): 0.000011 > Jan 8 08:30:53 server racoon: INFO: ISAKMP-SA established > IP1[4500]-EIP2[4500] spi:4d8718e1f5de6 2ad:be6f6325dd03507c > Jan 8 08:30:53 server racoon: alg_oakley_encdef_decrypt(3des klen=3D192 > size=3D56): 0.000010 > Jan 8 08:30:53 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D32): > 0.000013 > Jan 8 08:30:54 server racoon: INFO: initiate new phase 2 negotiation: > IP1[4500]<=3D>EIP2[4500] > Jan 8 08:30:54 server racoon: INFO: NAT detected -> UDP encapsulation > (ENC_MODE 1->3). > Jan 8 08:30:54 server racoon: INFO: NAT detected -> UDP encapsulation > (ENC_MODE 1->3). > Jan 8 08:30:54 server racoon: oakley_dh_generate(MODP768): 0.003996 > Jan 8 08:30:54 server racoon: alg_oakley_hmacdef_one(hmac_md5 size=3D244=): > 0.000009 > Jan 8 08:30:54 server racoon: alg_oakley_encdef_encrypt(3des klen=3D192 > size=3D264): 0.000029 > Jan 8 08:30:54 server racoon: phase2(quick I msg1): 0.004238 > Jan 8 08:31:09 server racoon: ERROR: EIP2 give up to get IPsec-SA due to > time up to wait.
It seems it breaks in phase 2. Can you check with ethereal/wireshark if you see any packets similar to the listing at the end of https://www.ipsec-howto.org/x304.html somewhere on your links?
> Any pointers or is this just not feasible with NAT at both ends?
It should work, but we need to find out what the two routers do with the packets.
Best regards, René.