DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default [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
fw1 ipsec.conf:
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
fw2 ipsec.conf:
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
I can ping and reach via ssh each fw, from the opposite one but I cannot reach the internal IP of the fw nor the network behind it.

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
fw2 ipsecctl -sa:
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
Errors on fw1:
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
Any help would be appreciated.

Last edited by da1; 1st October 2016 at 07:02 PM.
Reply With Quote
  #2   (View Single Post)  
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

I'll guess that you need to add a routing table entry so that the two gateways know how to find each other's internal networks.

For example, on fw1:

# route add 192.168.2.0/24 <ext_ip_fw2>
Reply With Quote
  #3   (View Single Post)  
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

UPDATE: I've noticed that with the above configuration, the pc's behind each fw, can reach their respective others from the other network.
Reply With Quote
  #4   (View Single Post)  
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

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.
Reply With Quote
  #5   (View Single Post)  
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

Are these connections tunnelled via esp, or are they in plaintext? You may find tcpdump(8) helpful to determine whether the connections are using the established SAs or not.
Reply With Quote
  #6   (View Single Post)  
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

Meanwhile, I'll assemble a group of virtual machines in my virtual lab and see if I can recreate the problem.
Reply With Quote
  #7   (View Single Post)  
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

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.
Reply With Quote
  #8   (View Single Post)  
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

Quote:
Originally Posted by jggimi View Post
Are these connections tunnelled via esp, or are they in plaintext? You may find tcpdump(8) helpful to determine whether the connections are using the established SAs or not.
tcpdump -vvv -ttt -n -i enc0:
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)
Reply With Quote
  #9   (View Single Post)  
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

I was able to recreate the environment. With isakmpd(8) started on both sides and no policies loaded (# isakmpd -K), the first side to receive IKE packets from the other logs refusal messages. I don't think this is a problem, as it has no policies loaded yet, it has not been instructed by ipsecctl and refuses packets which do not match isakmpd.policy(5) defaults.
Code:
133035.145727 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
133035.150594 Default message_negotiate_sa: no compatible proposal found
133035.155179 Default dropped message from 10.9.1.2 port 500 due to notification type NO_PROPOSAL_CHOSEN
Once ipsecctl is run on both gateways, policies match and IKE completes between the gateways..

Otherwise, everything seems to work for me. I ensured I had routing between the LANs before initiating IPSec.

Last edited by jggimi; 1st October 2016 at 05:56 PM. Reason: clarity regarding isakmpd policy
Reply With Quote
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

Must've been a classic PEBKAC problem then :P. I will continue to experiment.
Reply With Quote
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

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]
Reply With Quote
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

No need, thx again
Reply With Quote
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

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.
Reply With Quote
Old 1st October 2016
da1 da1 is offline
Fdisk Soldier
 
Join Date: Feb 2009
Location: Berlin, DE
Posts: 49
Default

Thx for confirming my PEBKAC presumption My self-esteem thanks you )
Reply With Quote
Old 1st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,794
Default

I don't think your issue is an "ID-ten-Tee" error.
  • I used your ipsec.conf file to set up the SAs and Flows.
  • I ran isakmpd with -Kvd to collect logs.
  • PF was the default wide-open pf.conf in my first test, and then a simple one line standard match out on egress from !(egress) nat-to (egress) copied and pasted from one of my machines, which is even more wide-open than the default.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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


All times are GMT. The time now is 08:25 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick