|
|||
[SOLVED]openbsd 6.0 ipsec issues
Hello everyone,
I'm struggling with this for too long and I need some help. The idea is to create an ipsec tunnel between 2 fw's, both running OpenBSD 6.0 amd64. Behind each fw, there is a small, class C network. Here is the configuration I have so far: - enc0 up on both fw's fw1/fw2 pf.conf (broad rules for testing): Code:
### Scrub >>> The first matching rule wins <<< match log on {$ext_if} all scrub (max-mss 1440 reassemble tcp) label "scrub" ### NAT & RDR >>> The first matching rule wins <<< match out log on {$ext_if} inet from !($ext_if:network) to any nat-to ($ext_if) label "NAT" set skip on enc0 block in log on $ext_if proto { tcp, udp, icmp } all label "EXT_IF block in" pass in log on $int_if all label "INT_IF pass in" pass out log label "DEF_PASS_OUT" pass in log on {$ext_if} proto udp from any to any port { 500 4500 } pass in log on {$ext_if} proto esp from any to any Code:
my_gw="<ext_ip_fw1>" my_net="192.168.1.0/24" gw2_gw="<ext_ip_fw2>" gw2_net="192.168.2.0/24" # me->gw2 ike esp from $my_gw to $gw2_gw peer $gw2_gw psk supersecretpsk ike esp from $my_gw to $gw2_net peer $gw2_gw psk supersecretpsk ike esp from $my_net to $gw2_net peer $gw2_gw psk supersecretpsk Code:
my_gw="<ext_ip_fw2>" my_net="192.168.2.0/24" gw1_gw="<ext_ip_fw1>" gw1_net="192.168.1.0/24" # me->gw1 ike esp from $my_gw to $gw1_gw peer $gw1_gw psk supersecretpsk ike esp from $my_gw to $gw1_net peer $gw1_gw psk supersecretpsk ike esp from $my_net to $gw1_net peer $gw1_gw psk supersecretpsk fw1 ipsecctl -sa: Code:
FLOWS: flow esp in from <ext_ip_fw2> to 192.168.1.0/24 peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type use flow esp out from 192.168.1.0/24 to <ext_ip_fw2> peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type require flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type use flow esp out from 192.168.1.0/24 to 192.168.2.0/24 peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type require flow esp in from <ext_ip_fw2> to <ext_ip_fw1> peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type use flow esp out from <ext_ip_fw1> to <ext_ip_fw2> peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type require flow esp in from 192.168.2.0/24 to <ext_ip_fw1> peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type use flow esp out from <ext_ip_fw1> to 192.168.2.0/24 peer <ext_ip_fw2> srcid <ext_ip_fw1>/32 dstid <ext_ip_fw2>/32 type require SAD: esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0x04480ae2 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0x2162a278 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0x28b321f0 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0x54f28ab7 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0x70d1b971 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0xc4959ca0 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0xe053b336 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0xe950c9d7 auth hmac-sha2-256 enc aes Code:
FLOWS: flow esp in from 192.168.1.0/24 to <ext_ip_fw2> peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type use flow esp out from <ext_ip_fw2> to 192.168.1.0/24 peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type require flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type use flow esp out from 192.168.2.0/24 to 192.168.1.0/24 peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type require flow esp in from <ext_ip_fw1> to <ext_ip_fw2> peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type use flow esp out from <ext_ip_fw2> to <ext_ip_fw1> peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type require flow esp in from <ext_ip_fw1> to 192.168.2.0/24 peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type use flow esp out from 192.168.2.0/24 to <ext_ip_fw1> peer <ext_ip_fw1> srcid <ext_ip_fw2>/32 dstid <ext_ip_fw1>/32 type require SAD: esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0x04480ae2 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0x2162a278 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0x28b321f0 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0x54f28ab7 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0x70d1b971 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw1> to <ext_ip_fw2> spi 0xc4959ca0 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0xe053b336 auth hmac-sha2-256 enc aes esp tunnel from <ext_ip_fw2> to <ext_ip_fw1> spi 0xe950c9d7 auth hmac-sha2-256 enc aes Code:
162458.953755 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id <ext_ip_fw2>, responder id <ext_ip_fw1> 162458.953798 Default dropped message from <ext_ip_fw2> port 500 due to notification type INVALID_ID_INFORMATION 162458.954654 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id <ext_ip_fw2>, responder id 192.168.1.0/255.255.255.0 162458.954665 Default dropped message from <ext_ip_fw2> port 500 due to notification type INVALID_ID_INFORMATION 162458.956722 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id 192.168.2.0/255.255.255.0, responder id 192.168.1.0/255.255.255.0 162458.956738 Default dropped message from <ext_ip_fw2> port 500 due to notification type INVALID_ID_INFORMATION 162505.956914 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload without a group desc. attribute 162505.956933 Default dropped message from <ext_ip_fw2> port 500 due to notification type NO_PROPOSAL_CHOSEN 162505.994418 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload without a group desc. attribute 162505.994430 Default dropped message from <ext_ip_fw2> port 500 due to notification type NO_PROPOSAL_CHOSEN 162506.104367 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload without a group desc. attribute 162506.104379 Default dropped message from <ext_ip_fw2> port 500 due to notification type NO_PROPOSAL_CHOSEN 162533.124444 Default transport_send_messages: giving up on exchange from-192.168.1.0/24-to-192.168.2.0/24, no response from peer <ext_ip_fw2>:500 162533.124476 Default transport_send_messages: giving up on exchange from-<ext_ip_fw1>-to-<ext_ip_fw2>, no response from peer <ext_ip_fw2>:500 162533.174432 Default transport_send_messages: giving up on exchange from-192.168.1.0/24-to-192.168.2.0/24, no response from peer <ext_ip_fw2>:500 errors on fw2: Code:
162506.032804 Default message_parse_payloads: invalid next payload type <Unknown 52> in payload of type 3 162506.032837 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162506.069356 Default message_parse_payloads: invalid next payload type <Unknown 41> in payload of type 3 162506.069363 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162506.142852 Default message_parse_payloads: invalid next payload type <Unknown 80> in payload of type 3 162506.142860 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162513.063324 Default message_parse_payloads: invalid next payload type <Unknown 52> in payload of type 3 162513.063344 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162513.083365 Default message_parse_payloads: invalid next payload type <Unknown 41> in payload of type 3 162513.083372 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162513.153363 Default message_parse_payloads: invalid next payload type <Unknown 80> in payload of type 3 162513.153371 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162522.092195 Default message_parse_payloads: invalid next payload type <Unknown 52> in payload of type 3 162522.092202 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162522.092379 Default message_parse_payloads: invalid next payload type <Unknown 41> in payload of type 3 162522.092386 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162522.162539 Default message_parse_payloads: invalid next payload type <Unknown 80> in payload of type 3 162522.162548 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162533.125326 Default message_parse_payloads: invalid next payload type <Unknown 52> in payload of type 3 162533.125335 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162533.125499 Default message_parse_payloads: invalid next payload type <Unknown 41> in payload of type 3 162533.125505 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE 162533.175514 Default message_parse_payloads: invalid next payload type <Unknown 80> in payload of type 3 162533.175523 Default dropped message from <ext_ip_fw1> port 500 due to notification type INVALID_PAYLOAD_TYPE Last edited by da1; 1st October 2016 at 07:02 PM. |
|
|||
UPDATE: I've noticed that with the above configuration, the pc's behind each fw, can reach their respective others from the other network.
|
|
|||
I thought so too but it seems it's not needed since I can reach 192.168.2.1 (fw2's LAN NIC) from fw1. Strange, it doesn't work the other way around.
|
|
|||
UPDATE: when using "ike passive" on fw2, the above scenario is recreatable for me. If I use "active" mode for ike (aka simply remove the "passive" keyword), the fw's and the pc's can reach each other bi-directional.
I've also added fw3 in the meantime and it seems fine. |
|
|||
Quote:
Code:
Oct 01 18:24:02.042642 (authentic,confidential): SPI 0xb034227e: ext_fw3 > ext_fw1: esp ext_fw3 > ext_fw1 spi 0x0eb58b4f seq 1697 len 88 (ttl 64, id 54376, len 108) (ttl 63, id 5953, len 128) Oct 01 18:24:02.042680 (authentic,confidential): SPI 0x0eb58b4f: ext_fw3 > ext_fw1: 192.168.3.100.51693 > 192.168.1.50.3389: . [tcp sum ok] 1:1(0) ack 561 win 16323 (ttl 127, id 23252, len 40) (ttl 64, id 54376, len 60) Oct 01 18:24:02.736887 (authentic,confidential): SPI 0xc8e2dfe6: ext_fw1 > ext_fw3: 192.168.1.50.63209 > 192.168.3.100.80: S [tcp sum ok] 622316736:622316736(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 29963, len 52) (DF) (ttl 64, id 5377, len 72, bad ip cksum 0! -> 33a9) Oct 01 18:24:02.736932 (authentic,confidential): SPI 0x3a8eda6f: ext_fw1 > ext_fw3: esp ext_fw1 > ext_fw3 spi 0xc8e2dfe6 seq 1835 len 104 (DF) (ttl 64, id 5377, len 124) (DF) (ttl 64, id 50213, len 144, bad ip cksum 0! -> 843c) Oct 01 18:24:02.883681 (authentic,confidential): SPI 0xc8e2dfe6: ext_fw1 > ext_fw3: 192.168.1.50.3389 > 192.168.3.100.51693: P 561:612(51) ack 1 win 63498 (DF) (ttl 127, id 29964, len 91) (DF) (ttl 64, id 38096, len 111, bad ip cksum 0! -> b3b2) Oct 01 18:24:02.883711 (authentic,confidential): SPI 0x3a8eda6f: ext_fw1 > ext_fw3: esp ext_fw1 > ext_fw3 spi 0xc8e2dfe6 seq 1836 len 136 (DF) (ttl 64, id 38096, len 156) (DF) (ttl 64, id 33650, len 176, bad ip cksum 0! -> c4cf) Oct 01 18:24:03.042897 (authentic,confidential): SPI 0xb034227e: ext_fw3 > ext_fw1: esp ext_fw3 > ext_fw1 spi 0x0eb58b4f seq 1698 len 88 (ttl 64, id 17238, len 108) (ttl 63, id 25882, len 128) Oct 01 18:24:03.042934 (authentic,confidential): SPI 0x0eb58b4f: ext_fw3 > ext_fw1: 192.168.3.100.51693 > 192.168.1.50.3389: . [tcp sum ok] 1:1(0) ack 612 win 16310 (ttl 127, id 23253, len 40) (ttl 64, id 17238, len 60) Oct 01 18:24:03.885677 (authentic,confidential): SPI 0xc8e2dfe6: ext_fw1 > ext_fw3: 192.168.1.50.3389 > 192.168.3.100.51693: P 612:663(51) ack 1 win 63498 (DF) (ttl 127, id 29965, len 91) (DF) (ttl 64, id 11910, len 111, bad ip cksum 0! -> 19fd) |
|
|||
Must've been a classic PEBKAC problem then :P. I will continue to experiment.
|
|
||||
My experiment was pretty simple.
[lan a] - [fw1] - [fw2] - [lan b] Because the subnet between the firewalls was not a "virtual internet," I could get away with simple default routes in all four nodes, without NAT. If you like, I can add a 5th virtual machine to simulate the Internet, add NAT, and test again. [lan a] - [fw1] - [Internet] - [fw2] - [lan b] |
|
|||
No need, thx again
|
|
||||
Too late. I wanted to test it anyway, so did. All my actual IPSec use had never used NAT, even when using tunnels instead of transport.
One cannot add routes to a non-routable subnet such as an RFC1918 address used in the test "lan a" or "lan b," but once the SAs and Flows are in place, routing between the subnets just works, because the traffic is tunnelled via the gateways. So there was no change in functionality. |
|
|||
Thx for confirming my PEBKAC presumption My self-esteem thanks you )
|
|
||||
I don't think your issue is an "ID-ten-Tee" error.
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
OpenBSD 5.1 ipsec pre-shared key not sending? | sparky | OpenBSD Security | 4 | 25th May 2012 01:47 PM |
OpenBSD Building VPN’s with OpenBSD and IPSEC | J65nko | News | 0 | 19th February 2011 07:53 PM |
Allegations regarding OpenBSD IPSEC | J65nko | News | 38 | 24th December 2010 09:22 AM |
OpenBSD IPSEC backdoored? | fender0107401 | OpenBSD Security | 1 | 15th December 2010 03:59 AM |
IPsec on openbsd | hitete | OpenBSD Installation and Upgrading | 1 | 12th July 2008 01:57 AM |