Cannot access network behind ipsec vpn

ipsec
vpn
v7

(Karl) #1

NethServer Version: release 7.5.1804 (final)
Module: nethserver-ipsec-tunnels 1.1.4 1.ns7

Connecting AWS ipsec VPN via libreswan - Tried everything, nothing works, no errors, no connection

Hello, I hope this hasn’t been asked anywhere else, but I couldn’t find it after searching for days.

All I want to do is access my server on aws via an aws managed ipsec vpn connection.

My setup is

[Webserver] AWS --> AWS VPN --> NethServer running libreswan

The NethServer runs libreswan. AWS has configuration instructions for openSWAN and strongSWAN but not libreswan so I’m following the general instructions.

I can make a successful connection, on NethServer (connection is green)

However I cannot access anything at all.
traceroute doesn’t even make a single hop, ping doesn’t get anywhere.

I tried route -e;
Destination Gateway Genmask Flags MSS Window irtt
169.254.. 0.0.0.0 255.255.255.252 U 0 0 0 eth0
169.254.. 0.0.0.0 255.255.255.252 U 0 0 0 eth0

traceroute ...
traceroute to ... (...), 30 hops max, 60 byte packets
1 * * *

But on AWS, the VPN connection says it’s UP, and again, NethServer says it’s successfully connected.


(Markus Neuberger) #2

Does your Nethserver have a public IP or is there some router in front of the Nethserver?
In case of a router you may have to setup a static route on the router from the ipsec network to your Nethserver.
I don’t use AWS (VPN), maybe you need some (virtual) routes there too.


(Rob Bosch) #3

Isn’t that (part of) a self assigned IP address (apipa)? That does not route too well…
More info on apipa in RFC 3926 https://www.ietf.org/rfc/rfc3927.txt


(Marc) #4

AWS uses them as inside addresses for the Virtual Private Gateway to prevent collisions.
Did not knew.


(Karl) #5

Hi everybody! Thanks for responding!

Some more information;

Yes, my NethServer does have a public IP, and that is the interface I’m using to connect.

Here are some screenshots of my configuration.

The 144 is my public IP address.
the 34 is the address I need to connect to.
The 20 is my local network
The 10 is the remote network

On the 10 network there is a machine I’m trying to connect to, but cannot because there is no pathway.

Here are some of the instructions that Amazon sent me:

IPSec Tunnel #1
================================================================================
#1: Internet Key Exchange Configuration
		
Configure the IKE SA as follows:
Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
The address of the external interface for your customer gateway must be a static address.
Your customer gateway may reside behind a device performing network address translation (NAT).
To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. If not behind NAT, we recommend disabling NAT-T.
  - IKE version              : IKEv1 
  - Authentication Method    : Pre-Shared Key 
  - Pre-Shared Key           : *******
  - Authentication Algorithm : sha1
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 28800 seconds
  - Phase 1 Negotiation Mode : main
  - Diffie-Hellman           : Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24.
Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
  - Protocol                 : esp
  - Authentication Algorithm : hmac-sha1-96
  - Encryption Algorithm     : aes-128-cbc
  - Lifetime                 : 3600 seconds
  - Mode                     : tunnel
  - Perfect Forward Secrecy  : Diffie-Hellman Group 2
	
IPSec Dead Peer Detection (DPD) will be enabled on the AWS Endpoint. We
recommend configuring DPD on your endpoint as follows:
  - DPD Interval             : 10
  - DPD Retries              : 3

IPSec ESP (Encapsulating Security Payload) inserts additional
headers to transmit packets. These headers require additional space, 
which reduces the amount of space available to transmit application data.
To limit the impact of this behavior, we recommend the following 
configuration on your Customer Gateway:
  - TCP MSS Adjustment       : 1379 bytes
  - Clear Don't Fragment Bit : enabled
  - Fragmentation            : Before encryption

#3: Tunnel Interface Configuration

Your Customer Gateway must be configured with a tunnel interface that is
associated with the IPSec tunnel. All traffic transmitted to the tunnel
interface is encrypted and transmitted to the Virtual Private Gateway.



The Customer Gateway and Virtual Private Gateway each have two addresses that relate
to this IPSec tunnel. Each contains an outside address, upon which encrypted
traffic is exchanged. Each also contain an inside address associated with
the tunnel interface.
 
The Customer Gateway outside IP address was provided when the Customer Gateway
was created. Changing the IP address requires the creation of a new
Customer Gateway.

The Customer Gateway inside IP address should be configured on your tunnel
interface. 

Outside IP Addresses:
  - Customer Gateway 		        : 144*******
  - Virtual Private Gateway	        : 34*********
		
Inside IP Addresses
  - Customer Gateway         		: 169.254.**.***/30
  - Virtual Private Gateway             : 169.254.**.***/30

Configure your tunnel to fragment at the optimal size:
  - Tunnel interface MTU     : 1436 bytes


#4: Static Routing Configuration:

To route traffic between your internal network and your VPC, 
you will need a static route added to your router.

Static Route Configuration Options:

  - Next hop       : 169.254.**.***
  
You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over 
the tunnels.

(Karl) #6

I’m using a public IP. You’re right, there are some virtual routes that need to be setup on AWS, however I have that part working.


(Karl) #7

Hey all,

Haven’t seen too many responses lately, Does anyone have any idea why I can’t access anything over my ipsec connection?

I’ll try uploading some logs later on, and see if anyone can spot something…


(Markus Neuberger) #8

Did you try to ping the IPSEC IP of the Nethserver from the AWS server and the other way round?
I never used AWS but in the static routes I can only see an IP but no interface or gateway.
You don’t have to setup a static route on your Nethserver.


(Karl) #9

On the AWS side, I have my local network being propagated to the remote AWS network route table.
So when I am connection over IPSEC my local 20 network shows as propagated. When I examine the AWS route table for my 10 network, I see my 20 network being propagates to it.

However, if I connect to my AWS server to ping my local 20 network, I get nothing, sometimes I get ‘no route to host’. If I do ‘route -e’ my 20 network isn’t on there.

This is what makes it so frustrating, because for the most part, it looks like everything is working, just not at the very end.


(Markus Neuberger) #10

Can you ping the routers IPs? If you can ping the routers itself but can’t ping another device on remote network it may be a routing problem.

I hope you can find some errors in the logs.


(Karl) #11

OK, that was odd.

First I started the IPSEC VPN and got a successful connection.

I connect to my aws server on the 10 network.

first I run route -e

route -e

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default ip-10---.us 0.0.0.0 UG 0 0 0 ens3
10.
.. 0.0.0.0 255.255.255.0 U 0 0 0 ens3

So there is no 20 network, even though AWS says the network is propagated.

from this aws server I ping the local router on the 20 network.

ping 20

PING 20 (20) 56(84) bytes of data.
64 bytes from 20: icmp_seq=1 ttl=64 time=10.1 ms
64 bytes from 20: icmp_seq=2 ttl=64 time=9.78 ms
64 bytes from 20: icmp_seq=3 ttl=64 time=9.85 ms

then tracepath

tracepath 20.8.1.3

1?: [LOCALHOST] pmtu 9001
1: ip-10-0--.us-west-2.compute.internal 0.208ms pmtu 1500
1: 169.254.. 1.370ms pmtu 1422
1: 20...* 9.153ms reached
Resume: pmtu 1422 hops 1 back 1

Meanwhile on the local router on the 10 network.

route -e

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 144(public IP) 0.0.0.0 UG 0 0 0 eth0
10 0.0.0.0 255.255.0.0 U 0 0 0 eth0
20 0.0.0.0 255.255.255.0 U 0 0 0 eth1

and a ping to the 10 network, basically nothing was reachable.


(Karl) #12

Here is the log file generated from a single connection to the aws ipsec vpn

Sep  8 21:00:57.195018: | timer_event_cb: processing event@0x5583ba544728
Sep  8 21:00:57.195080: | handling event EVENT_SHUNT_SCAN
Sep  8 21:00:57.195087: | expiring aged bare shunts
Sep  8 21:00:57.195094: | event_schedule: new EVENT_SHUNT_SCAN-pe@0x5583ba555e88
Sep  8 21:00:57.195117: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds
Sep  8 21:00:57.195130: | free_event_entry: release EVENT_SHUNT_SCAN-pe@0x5583ba544728
Sep  8 21:00:59.100910: | *received 92 bytes from 34.*.*.*:4500 on eth0 (port=4500)
Sep  8 21:00:59.100962: |   f5 81 e0 ee  8a 30 73 0e  1f 42 37 27  30 b7 17 f4
Sep  8 21:00:59.100966: |   08 10 05 01  df 3e ac 00  00 00 00 5c  a7 de 93 da
Sep  8 21:00:59.100969: |   a7 06 2f bb  6a a1 e3 9e  f5 1f 97 70  ad 82 f3 9a
Sep  8 21:00:59.100972: |   f5 17 f5 24  8d 14 4a ae  a0 7b 0c 6c  84 6f e2 1f
Sep  8 21:00:59.100974: |   da 86 e2 ca  79 72 a3 5f  38 ba 0d 8a  3e 9a 8e 9f
Sep  8 21:00:59.101003: |   a0 4d e9 19  04 0b 85 3b  4a 0c ab 54
Sep  8 21:00:59.101011: | processing: start from 34.*.*.*:4500 (in comm_handle() at demux.c:373)
Sep  8 21:00:59.101017: | **parse ISAKMP Message:
Sep  8 21:00:59.101021: |    initiator cookie:
Sep  8 21:00:59.101024: |   f5 81 e0 ee  8a 30 73 0e
Sep  8 21:00:59.101027: |    responder cookie:
Sep  8 21:00:59.101030: |   1f 42 37 27  30 b7 17 f4
Sep  8 21:00:59.101038: |    next payload type: ISAKMP_NEXT_HASH (0x8)
Sep  8 21:00:59.101044: |    ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)
Sep  8 21:00:59.101047: |    exchange type: ISAKMP_XCHG_INFO (0x5)
Sep  8 21:00:59.101051: |    flags: ISAKMP_FLAG_v1_ENCRYPTION (0x1)
Sep  8 21:00:59.101054: |    message ID:  df 3e ac 00
Sep  8 21:00:59.101058: |    length: 92 (0x5c)
Sep  8 21:00:59.101061: |  processing version=1.0 packet with exchange type=ISAKMP_XCHG_INFO (5)
Sep  8 21:00:59.101073: | cookies table: hash icookie f5 81 e0 ee  8a 30 73 0e rcookie 1f 42 37 27  30 b7 17 f4 to 9627849172733471558 slot 0x5583b8dde360
Sep  8 21:00:59.101078: | peer and cookies match on #2; msgid=00000000 st_msgid=b6f4d574 st_msgid_phase15=00000000
Sep  8 21:00:59.101081: | peer and cookies match on #1; msgid=00000000 st_msgid=00000000 st_msgid_phase15=00000000
Sep  8 21:00:59.101085: | p15 state object #1 found, in STATE_MAIN_I4
Sep  8 21:00:59.101093: | processing: start state #1 connection "webhost_aws_1_ipsec-tunnel/1x1" 34.*.*.*:4500 (in process_v1_packet() at ikev1.c:1145)
Sep  8 21:00:59.101099: | last Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:00:59.101102: | current Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:00:59.101106: | IV hash sha init
Sep  8 21:00:59.101151: | IV sha hasher: context 0x5583ba544700
Sep  8 21:00:59.101161: | IV hash sha digest PH1_IV-bytes@0x5583ba54e208 (length 16)
Sep  8 21:00:59.101173: | IV hash sha digest MSGID-bytes@0x5583ba54e8bc (length 4)
Sep  8 21:00:59.101177: | IV hash sha final bytes@0x5583ba54e188 (length 20)
Sep  8 21:00:59.101187: | IV  92 a1 36 08  0a ab 16 63  9d a3 c9 a4  47 d7 9c fd
Sep  8 21:00:59.101190: | IV  ec 64 e8 1d
Sep  8 21:00:59.101194: | computed Phase 2 IV:
Sep  8 21:00:59.101196: |   92 a1 36 08  0a ab 16 63  9d a3 c9 a4  47 d7 9c fd
Sep  8 21:00:59.101199: |   ec 64 e8 1d
Sep  8 21:00:59.101203: | #1 is idle
Sep  8 21:00:59.101206: | #1 idle
Sep  8 21:00:59.101210: | received encrypted packet from 34.*.*.*:4500
Sep  8 21:00:59.101214: | decrypting 64 bytes using algorithm AES_CBC
Sep  8 21:00:59.101218: | NSS ike_alg_nss_cbc: aes - enter
Sep  8 21:00:59.101237: | NSS ike_alg_nss_cbc: aes - exit
Sep  8 21:00:59.101240: | decrypted:
Sep  8 21:00:59.101243: |   0b 00 00 18  bd 54 1f 31  78 5c cf 96  83 b1 34 46
Sep  8 21:00:59.101246: |   de 6a bf 3f  bb d1 87 d8  00 00 00 20  00 00 00 01
Sep  8 21:00:59.101248: |   01 10 8d 28  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27
Sep  8 21:00:59.101251: |   30 b7 17 f4  00 00 62 34  00 00 00 00  00 00 00 00
Sep  8 21:00:59.101254: | next IV:  3e 9a 8e 9f  a0 4d e9 19  04 0b 85 3b  4a 0c ab 54
Sep  8 21:00:59.101258: | got payload 0x100  (ISAKMP_NEXT_HASH) needed: 0x100opt: 0x0
Sep  8 21:00:59.101262: | ***parse ISAKMP Hash Payload:
Sep  8 21:00:59.101265: |    next payload type: ISAKMP_NEXT_N (0xb)
Sep  8 21:00:59.101268: |    length: 24 (0x18)
Sep  8 21:00:59.101286: | got payload 0x800  (ISAKMP_NEXT_N) needed: 0x0opt: 0x0
Sep  8 21:00:59.101291: | ***parse ISAKMP Notification Payload:
Sep  8 21:00:59.101294: |    next payload type: ISAKMP_NEXT_NONE (0x0)
Sep  8 21:00:59.101296: |    length: 32 (0x20)
Sep  8 21:00:59.101299: |    DOI: ISAKMP_DOI_IPSEC (0x1)
Sep  8 21:00:59.101302: |    protocol ID: 1 (0x1)
Sep  8 21:00:59.101305: |    SPI size: 16 (0x10)
Sep  8 21:00:59.101308: |    Notify Message Type: R_U_THERE (0x8d28)
Sep  8 21:00:59.101311: | removing 8 bytes of padding
Sep  8 21:00:59.101314: | info:  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27  30 b7 17 f4
Sep  8 21:00:59.101316: | info:  00 00 62 34
Sep  8 21:00:59.101320: | processing informational R_U_THERE (36136)
Sep  8 21:00:59.101328: | DPD: received R_U_THERE seq:25140 monotime:640834.307 (state=#1 name="webhost_aws_1_ipsec-tunnel/1x1")
Sep  8 21:00:59.101339: | **emit ISAKMP Message:
Sep  8 21:00:59.101342: |    initiator cookie:
Sep  8 21:00:59.101345: |   f5 81 e0 ee  8a 30 73 0e
Sep  8 21:00:59.101348: |    responder cookie:
Sep  8 21:00:59.101350: |   1f 42 37 27  30 b7 17 f4
Sep  8 21:00:59.101353: |    next payload type: ISAKMP_NEXT_HASH (0x8)
Sep  8 21:00:59.101356: |    ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)
Sep  8 21:00:59.101359: |    exchange type: ISAKMP_XCHG_INFO (0x5)
Sep  8 21:00:59.101362: |    flags: ISAKMP_FLAG_v1_ENCRYPTION (0x1)
Sep  8 21:00:59.101364: |    message ID:  1d e7 76 41
Sep  8 21:00:59.101368: | ***emit ISAKMP Hash Payload:
Sep  8 21:00:59.101371: |    next payload type: ISAKMP_NEXT_N (0xb)
Sep  8 21:00:59.101374: | emitting 20 zero bytes of HASH into ISAKMP Hash Payload
Sep  8 21:00:59.101377: | emitting length of ISAKMP Hash Payload: 24
Sep  8 21:00:59.101380: | ***emit ISAKMP Notification Payload:
Sep  8 21:00:59.101383: |    next payload type: ISAKMP_NEXT_NONE (0x0)
Sep  8 21:00:59.101385: |    DOI: ISAKMP_DOI_IPSEC (0x1)
Sep  8 21:00:59.101388: |    protocol ID: 1 (0x1)
Sep  8 21:00:59.101391: |    SPI size: 16 (0x10)
Sep  8 21:00:59.101394: |    Notify Message Type: R_U_THERE_ACK (0x8d29)
Sep  8 21:00:59.101398: | emitting 8 raw bytes of notify icookie into ISAKMP Notification Payload
Sep  8 21:00:59.101401: | notify icookie  f5 81 e0 ee  8a 30 73 0e
Sep  8 21:00:59.101404: | emitting 8 raw bytes of notify rcookie into ISAKMP Notification Payload
Sep  8 21:00:59.101406: | notify rcookie  1f 42 37 27  30 b7 17 f4
Sep  8 21:00:59.101409: | emitting 4 raw bytes of notify data into ISAKMP Notification Payload
Sep  8 21:00:59.101412: | notify data  00 00 62 34
Sep  8 21:00:59.101415: | emitting length of ISAKMP Notification Payload: 32
Sep  8 21:00:59.101420: | hmac PRF sha init symkey-key@0x7f76680059f0 (size 20)
Sep  8 21:00:59.101424: | EXTRACT_KEY_FROM_KEY:
Sep  8 21:00:59.101428: |     key-key@0x7f76680059f0, size: 20 bytes, type/mechanism: EXTRACT_KEY_FROM_KEY
Sep  8 21:00:59.101431: |     key-offset: 0, key-size: 20
Sep  8 21:00:59.101434: |     -> flags: SIGN target: SHA_1_HMAC
Sep  8 21:00:59.101454: |     result: clone-key@0x5583ba54fb80, size: 20 bytes, type/mechanism: SHA_1_HMAC
Sep  8 21:00:59.101464: | hmac prf: created sha context 0x5583ba544700 from symkey-key@0x5583ba54fb80
Sep  8 21:00:59.101467: | hmac prf: begin sha with context 0x5583ba544700 from symkey-key@0x5583ba54fb80
Sep  8 21:00:59.101471: | hmac: release clone-key@0x5583ba54fb80
Sep  8 21:00:59.101474: | hmac PRF sha crypt-prf@0x5583ba555ef8
Sep  8 21:00:59.101478: | hmac PRF sha update data-bytes@0x7ffc39b4c6ec (length 4)
Sep  8 21:00:59.101482: | hmac PRF sha update data-bytes@0x5583b8df1494 (length 32)
Sep  8 21:00:59.101485: | hmac PRF sha final-bytes ...
Sep  8 21:00:59.101493: | hmac PRF sha final-bytes@0x5583b8df1480 (length 20)
Sep  8 21:00:59.101496: | HASH computed:
Sep  8 21:00:59.101499: |   7f a2 a2 b9  41 ca 71 ba  90 6c af c6  cb 6c 7b 53
Sep  8 21:00:59.101501: |   c8 18 9b 41
Sep  8 21:00:59.101504: | last Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:00:59.101507: | current Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:00:59.101515: | IV hash sha init
Sep  8 21:00:59.101844: | IV sha hasher: context 0x5583ba544700
Sep  8 21:00:59.101901: | IV hash sha digest PH1_IV-bytes@0x5583ba54e208 (length 16)
Sep  8 21:00:59.101914: | IV hash sha digest MSGID-bytes@0x7ffc39b4c6ec (length 4)
Sep  8 21:00:59.101921: | IV hash sha final bytes@0x5583ba54e188 (length 20)
Sep  8 21:00:59.101938: | IV  42 25 12 38  69 77 ff 40  e8 04 89 07  87 22 66 9b
Sep  8 21:00:59.101943: | IV  02 5a b0 e2
Sep  8 21:00:59.101949: | computed Phase 2 IV:
Sep  8 21:00:59.101953: |   42 25 12 38  69 77 ff 40  e8 04 89 07  87 22 66 9b
Sep  8 21:00:59.101957: |   02 5a b0 e2
Sep  8 21:00:59.101963: | encrypting:  0b 00 00 18  7f a2 a2 b9  41 ca 71 ba  90 6c af c6
Sep  8 21:00:59.101967: | encrypting:  cb 6c 7b 53  c8 18 9b 41  00 00 00 20  00 00 00 01
Sep  8 21:00:59.101972: | encrypting:  01 10 8d 29  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27
Sep  8 21:00:59.102012: | encrypting:  30 b7 17 f4  00 00 62 34
Sep  8 21:00:59.102036: | IV:  42 25 12 38  69 77 ff 40  e8 04 89 07  87 22 66 9b
Sep  8 21:00:59.102041: | IV:  02 5a b0 e2
Sep  8 21:00:59.102045: | unpadded size is: 56
Sep  8 21:00:59.102052: | emitting 8 zero bytes of encryption padding into ISAKMP Message
Sep  8 21:00:59.102057: | encrypting 64 using AES_CBC
Sep  8 21:00:59.102063: | NSS ike_alg_nss_cbc: aes - enter
Sep  8 21:00:59.102102: | NSS ike_alg_nss_cbc: aes - exit
Sep  8 21:00:59.102110: | next IV:  70 c4 a0 2f  6f 7c ce ef  bb fd 73 2a  38 a1 45 e1
Sep  8 21:00:59.102115: | no IKEv1 message padding required
Sep  8 21:00:59.102121: | emitting length of ISAKMP Message: 92
Sep  8 21:00:59.102136: | sending 96 bytes for ISAKMP notify through eth0:4500 to 34.*.*.*:4500 (using #1)
Sep  8 21:00:59.102142: |   00 00 00 00  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27
Sep  8 21:00:59.102147: |   30 b7 17 f4  08 10 05 01  1d e7 76 41  00 00 00 5c
Sep  8 21:00:59.102151: |   51 f5 40 22  78 b6 7c 4b  8a fc 87 e7  d7 45 26 28
Sep  8 21:00:59.102156: |   05 e0 5d 9b  65 1e d8 b1  74 51 92 5d  2a a3 b2 2e
Sep  8 21:00:59.102160: |   0d 8b da 58  2a 16 38 7a  67 e4 91 34  de 42 e8 0e
Sep  8 21:00:59.102165: |   70 c4 a0 2f  6f 7c ce ef  bb fd 73 2a  38 a1 45 e1
Sep  8 21:00:59.102327: | complete v1 state transition with STF_IGNORE
Sep  8 21:00:59.102345: | processing: stop from 34.*.*.*:4500 (BACKGROUND) (in comm_handle() at demux.c:375)
Sep  8 21:00:59.102358: | processing: stop state #1 connection "webhost_aws_1_ipsec-tunnel/1x1" 34.*.*.*:4500 (in comm_handle() at demux.c:380)
Sep  8 21:00:59.102366: | serialno table: hash serialno #0 to head 0x5583b8de5220
Sep  8 21:00:59.102412: | serialno table: hash serialno #0 to head 0x5583b8de5220
Sep  8 21:00:59.102420: | processing: STOP connection NULL (in comm_handle() at demux.c:381)
Sep  8 21:01:09.127473: | *received 92 bytes from 34.*.*.*:4500 on eth0 (port=4500)
Sep  8 21:01:09.127533: |   f5 81 e0 ee  8a 30 73 0e  1f 42 37 27  30 b7 17 f4
Sep  8 21:01:09.127538: |   08 10 05 01  c6 c5 67 03  00 00 00 5c  8d c5 77 e9
Sep  8 21:01:09.127541: |   89 63 b4 b5  ea d6 98 a0  37 36 9b 0c  9b df bc 83
Sep  8 21:01:09.127544: |   73 86 34 04  71 68 6e 8a  15 4f 55 31  59 d3 b3 dd
Sep  8 21:01:09.127547: |   a9 35 f1 6f  0d fc 81 27  01 3c 58 45  68 ae 41 b6
Sep  8 21:01:09.127549: |   b7 fe 72 a7  6b 95 b7 cd  95 b5 2f ef
Sep  8 21:01:09.127562: | processing: start from 34.*.*.*:4500 (in comm_handle() at demux.c:373)
Sep  8 21:01:09.127577: | **parse ISAKMP Message:
Sep  8 21:01:09.127581: |    initiator cookie:
Sep  8 21:01:09.127584: |   f5 81 e0 ee  8a 30 73 0e
Sep  8 21:01:09.127587: |    responder cookie:
Sep  8 21:01:09.127738: |   1f 42 37 27  30 b7 17 f4
Sep  8 21:01:09.127745: |    next payload type: ISAKMP_NEXT_HASH (0x8)
Sep  8 21:01:09.127750: |    ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)
Sep  8 21:01:09.127755: |    exchange type: ISAKMP_XCHG_INFO (0x5)
Sep  8 21:01:09.127761: |    flags: ISAKMP_FLAG_v1_ENCRYPTION (0x1)
Sep  8 21:01:09.127766: |    message ID:  c6 c5 67 03
Sep  8 21:01:09.127770: |    length: 92 (0x5c)
Sep  8 21:01:09.127776: |  processing version=1.0 packet with exchange type=ISAKMP_XCHG_INFO (5)
Sep  8 21:01:09.127820: | cookies table: hash icookie f5 81 e0 ee  8a 30 73 0e rcookie 1f 42 37 27  30 b7 17 f4 to 9627849172733471558 slot 0x5583b8dde360
Sep  8 21:01:09.127836: | peer and cookies match on #2; msgid=00000000 st_msgid=b6f4d574 st_msgid_phase15=00000000
Sep  8 21:01:09.127843: | peer and cookies match on #1; msgid=00000000 st_msgid=00000000 st_msgid_phase15=00000000
Sep  8 21:01:09.127848: | p15 state object #1 found, in STATE_MAIN_I4
Sep  8 21:01:09.127863: | processing: start state #1 connection "webhost_aws_1_ipsec-tunnel/1x1" 34.*.*.*:4500 (in process_v1_packet() at ikev1.c:1145)
Sep  8 21:01:09.127881: | last Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:01:09.127894: | current Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:01:09.127904: | IV hash sha init
Sep  8 21:01:09.128047: | IV sha hasher: context 0x5583ba544700
Sep  8 21:01:09.128066: | IV hash sha digest PH1_IV-bytes@0x5583ba54e208 (length 16)
Sep  8 21:01:09.128075: | IV hash sha digest MSGID-bytes@0x5583ba54e8bc (length 4)
Sep  8 21:01:09.128081: | IV hash sha final bytes@0x5583ba54e188 (length 20)
Sep  8 21:01:09.128103: | IV  98 8f cb 02  f6 8e 7e 80  a7 ce cb 6d  1c e4 fb 69
Sep  8 21:01:09.128109: | IV  ba 4d 4d 06
Sep  8 21:01:09.128115: | computed Phase 2 IV:
Sep  8 21:01:09.128119: |   98 8f cb 02  f6 8e 7e 80  a7 ce cb 6d  1c e4 fb 69
Sep  8 21:01:09.128123: |   ba 4d 4d 06
Sep  8 21:01:09.128133: | #1 is idle
Sep  8 21:01:09.128137: | #1 idle
Sep  8 21:01:09.128144: | received encrypted packet from 34.*.*.*:4500
Sep  8 21:01:09.128149: | decrypting 64 bytes using algorithm AES_CBC
Sep  8 21:01:09.128155: | NSS ike_alg_nss_cbc: aes - enter
Sep  8 21:01:09.128197: | NSS ike_alg_nss_cbc: aes - exit
Sep  8 21:01:09.128204: | decrypted:
Sep  8 21:01:09.128208: |   0b 00 00 18  94 b4 f4 30  f2 b2 dd 3d  16 87 55 c0
Sep  8 21:01:09.128213: |   71 c9 38 ae  b9 cd c0 d7  00 00 00 20  00 00 00 01
Sep  8 21:01:09.128218: |   01 10 8d 28  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27
Sep  8 21:01:09.128223: |   30 b7 17 f4  00 00 62 35  00 00 00 00  00 00 00 00
Sep  8 21:01:09.128227: | next IV:  68 ae 41 b6  b7 fe 72 a7  6b 95 b7 cd  95 b5 2f ef
Sep  8 21:01:09.128238: | got payload 0x100  (ISAKMP_NEXT_HASH) needed: 0x100opt: 0x0
Sep  8 21:01:09.128248: | ***parse ISAKMP Hash Payload:
Sep  8 21:01:09.128253: |    next payload type: ISAKMP_NEXT_N (0xb)
Sep  8 21:01:09.128256: |    length: 24 (0x18)
Sep  8 21:01:09.128260: | got payload 0x800  (ISAKMP_NEXT_N) needed: 0x0opt: 0x0
Sep  8 21:01:09.128267: | ***parse ISAKMP Notification Payload:
Sep  8 21:01:09.128270: |    next payload type: ISAKMP_NEXT_NONE (0x0)
Sep  8 21:01:09.128273: |    length: 32 (0x20)
Sep  8 21:01:09.128276: |    DOI: ISAKMP_DOI_IPSEC (0x1)
Sep  8 21:01:09.128279: |    protocol ID: 1 (0x1)
Sep  8 21:01:09.128281: |    SPI size: 16 (0x10)
Sep  8 21:01:09.128284: |    Notify Message Type: R_U_THERE (0x8d28)
Sep  8 21:01:09.128287: | removing 8 bytes of padding
Sep  8 21:01:09.128290: | info:  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27  30 b7 17 f4
Sep  8 21:01:09.128293: | info:  00 00 62 35
Sep  8 21:01:09.128296: | processing informational R_U_THERE (36136)
Sep  8 21:01:09.128305: | DPD: received R_U_THERE seq:25141 monotime:640844.334 (state=#1 name="webhost_aws_1_ipsec-tunnel/1x1")
Sep  8 21:01:09.128324: | **emit ISAKMP Message:
Sep  8 21:01:09.128328: |    initiator cookie:
Sep  8 21:01:09.128331: |   f5 81 e0 ee  8a 30 73 0e
Sep  8 21:01:09.128334: |    responder cookie:
Sep  8 21:01:09.128336: |   1f 42 37 27  30 b7 17 f4
Sep  8 21:01:09.128339: |    next payload type: ISAKMP_NEXT_HASH (0x8)
Sep  8 21:01:09.128342: |    ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)
Sep  8 21:01:09.128345: |    exchange type: ISAKMP_XCHG_INFO (0x5)
Sep  8 21:01:09.128348: |    flags: ISAKMP_FLAG_v1_ENCRYPTION (0x1)
Sep  8 21:01:09.128351: |    message ID:  53 2c 00 dc
Sep  8 21:01:09.128355: | ***emit ISAKMP Hash Payload:
Sep  8 21:01:09.128358: |    next payload type: ISAKMP_NEXT_N (0xb)
Sep  8 21:01:09.128368: | emitting 20 zero bytes of HASH into ISAKMP Hash Payload
Sep  8 21:01:09.128372: | emitting length of ISAKMP Hash Payload: 24
Sep  8 21:01:09.128374: | ***emit ISAKMP Notification Payload:
Sep  8 21:01:09.128377: |    next payload type: ISAKMP_NEXT_NONE (0x0)
Sep  8 21:01:09.128380: |    DOI: ISAKMP_DOI_IPSEC (0x1)
Sep  8 21:01:09.128383: |    protocol ID: 1 (0x1)
Sep  8 21:01:09.128385: |    SPI size: 16 (0x10)
Sep  8 21:01:09.128388: |    Notify Message Type: R_U_THERE_ACK (0x8d29)
Sep  8 21:01:09.128396: | emitting 8 raw bytes of notify icookie into ISAKMP Notification Payload
Sep  8 21:01:09.128399: | notify icookie  f5 81 e0 ee  8a 30 73 0e
Sep  8 21:01:09.128402: | emitting 8 raw bytes of notify rcookie into ISAKMP Notification Payload
Sep  8 21:01:09.128405: | notify rcookie  1f 42 37 27  30 b7 17 f4
Sep  8 21:01:09.128408: | emitting 4 raw bytes of notify data into ISAKMP Notification Payload
Sep  8 21:01:09.128411: | notify data  00 00 62 35
Sep  8 21:01:09.128414: | emitting length of ISAKMP Notification Payload: 32
Sep  8 21:01:09.128419: | hmac PRF sha init symkey-key@0x7f76680059f0 (size 20)
Sep  8 21:01:09.128423: | EXTRACT_KEY_FROM_KEY:
Sep  8 21:01:09.128427: |     key-key@0x7f76680059f0, size: 20 bytes, type/mechanism: EXTRACT_KEY_FROM_KEY
Sep  8 21:01:09.128430: |     key-offset: 0, key-size: 20
Sep  8 21:01:09.128433: |     -> flags: SIGN target: SHA_1_HMAC
Sep  8 21:01:09.128462: |     result: clone-key@0x5583ba54fb80, size: 20 bytes, type/mechanism: SHA_1_HMAC
Sep  8 21:01:09.128473: | hmac prf: created sha context 0x5583ba544700 from symkey-key@0x5583ba54fb80
Sep  8 21:01:09.128477: | hmac prf: begin sha with context 0x5583ba544700 from symkey-key@0x5583ba54fb80
Sep  8 21:01:09.128480: | hmac: release clone-key@0x5583ba54fb80
Sep  8 21:01:09.128483: | hmac PRF sha crypt-prf@0x5583ba53ee48
Sep  8 21:01:09.128490: | hmac PRF sha update data-bytes@0x7ffc39b4c6ec (length 4)
Sep  8 21:01:09.128495: | hmac PRF sha update data-bytes@0x5583b8df1494 (length 32)
Sep  8 21:01:09.128498: | hmac PRF sha final-bytes ...
Sep  8 21:01:09.128506: | hmac PRF sha final-bytes@0x5583b8df1480 (length 20)
Sep  8 21:01:09.128509: | HASH computed:
Sep  8 21:01:09.128512: |   74 01 c4 01  69 32 b2 c7  ae 5b a8 49  70 22 86 d3
Sep  8 21:01:09.128515: |   ca 47 6a af
Sep  8 21:01:09.128518: | last Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:01:09.128521: | current Phase 1 IV:  ea 99 9c 34  10 45 d6 4f  8f 41 ed bc  b4 7e 23 96
Sep  8 21:01:09.128523: | IV hash sha init
Sep  8 21:01:09.128529: | IV sha hasher: context 0x5583ba544700
Sep  8 21:01:09.128532: | IV hash sha digest PH1_IV-bytes@0x5583ba54e208 (length 16)
Sep  8 21:01:09.128536: | IV hash sha digest MSGID-bytes@0x7ffc39b4c6ec (length 4)
Sep  8 21:01:09.128539: | IV hash sha final bytes@0x5583ba54e188 (length 20)
Sep  8 21:01:09.128544: | IV  e4 b7 b9 35  30 50 b2 ff  7a b6 a3 28  91 d5 57 cb
Sep  8 21:01:09.128548: | IV  05 c4 07 64
Sep  8 21:01:09.128552: | computed Phase 2 IV:
Sep  8 21:01:09.128556: |   e4 b7 b9 35  30 50 b2 ff  7a b6 a3 28  91 d5 57 cb
Sep  8 21:01:09.128560: |   05 c4 07 64
Sep  8 21:01:09.128570: | encrypting:  0b 00 00 18  74 01 c4 01  69 32 b2 c7  ae 5b a8 49
Sep  8 21:01:09.128575: | encrypting:  70 22 86 d3  ca 47 6a af  00 00 00 20  00 00 00 01
Sep  8 21:01:09.128579: | encrypting:  01 10 8d 29  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27
Sep  8 21:01:09.128583: | encrypting:  30 b7 17 f4  00 00 62 35
Sep  8 21:01:09.128588: | IV:  e4 b7 b9 35  30 50 b2 ff  7a b6 a3 28  91 d5 57 cb
Sep  8 21:01:09.128601: | IV:  05 c4 07 64
Sep  8 21:01:09.128606: | unpadded size is: 56
Sep  8 21:01:09.128611: | emitting 8 zero bytes of encryption padding into ISAKMP Message
Sep  8 21:01:09.128615: | encrypting 64 using AES_CBC
Sep  8 21:01:09.128620: | NSS ike_alg_nss_cbc: aes - enter
Sep  8 21:01:09.128635: | NSS ike_alg_nss_cbc: aes - exit
Sep  8 21:01:09.128640: | next IV:  8f 09 cf fb  75 da f7 f1  95 57 e0 a2  69 c7 c9 0c
Sep  8 21:01:09.128645: | no IKEv1 message padding required
Sep  8 21:01:09.128656: | emitting length of ISAKMP Message: 92
Sep  8 21:01:09.128665: | sending 96 bytes for ISAKMP notify through eth0:4500 to 34.*.*.*:4500 (using #1)
Sep  8 21:01:09.128671: |   00 00 00 00  f5 81 e0 ee  8a 30 73 0e  1f 42 37 27
Sep  8 21:01:09.128675: |   30 b7 17 f4  08 10 05 01  53 2c 00 dc  00 00 00 5c
Sep  8 21:01:09.128679: |   96 28 f6 75  50 57 ce 47  6f ba 3d 8e  47 20 fd 66
Sep  8 21:01:09.128683: |   ca 75 54 d4  15 37 4b e0  4a fe 35 9a  a3 55 e6 0f
Sep  8 21:01:09.128687: |   dc ae 72 ac  5f 4e 20 2c  5a d8 25 a3  c3 56 a4 62
Sep  8 21:01:09.128692: |   8f 09 cf fb  75 da f7 f1  95 57 e0 a2  69 c7 c9 0c
Sep  8 21:01:09.128771: | complete v1 state transition with STF_IGNORE
Sep  8 21:01:09.128784: | processing: stop from 34.*.*.*:4500 (BACKGROUND) (in comm_handle() at demux.c:375)
Sep  8 21:01:09.128791: | processing: stop state #1 connection "webhost_aws_1_ipsec-tunnel/1x1" 34.*.*.*:4500 (in comm_handle() at demux.c:380)
Sep  8 21:01:09.128795: | serialno table: hash serialno #0 to head 0x5583b8de5220
Sep  8 21:01:09.128803: | serialno table: hash serialno #0 to head 0x5583b8de5220
Sep  8 21:01:09.128810: | processing: STOP connection NULL (in comm_handle() at demux.c:381)

(Karl) #13

Hi all, just a quick bump. As you see from the post above it looks like the remote network knows how to reach me, but my network doesn’t know how to reach it.

Do I need to add static route? If so, any idea what the gateway would be?