IKEv2 vpn between OpenBSD 6.2 and Cisco ASA 5510 using PSK
d71a9 ikev2_recv: IKE_AUTH request from initiator 2.2.2.2:500 to 1.1.1.1:500 policy 'DO-test' id 1, 332 bytes ikev2_recv: ispi 0xaf51a28350f1c918 rspi 0xac9649f5b88d71a9 ^Ccontrol exiting, pid 27599 ikev2 exiting, pid 62350 ca exiting, pid 73320 parent terminating To me it looks like it has authenticated but still requires a certificate?!? I can post the Cisco debugging output if required but in order to not make this post too verbose I'll defer with that. Hopefully somebody has a solution or even suggestions are much appreciated. Thanks, Danial -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: iked random tunnel drops
I had something similar happening. In my case I solved it by disabling NAT-T on one end. / Danial -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: IKEv2 vpn between OpenBSD 6.2 and Cisco ASA 5510 using PSK
I'll answer my own post. I've come to the conclusion that the OpenBSD IKEv2 implementation in iked is incompatible with Cisco. It works between OpenBSD boxes but none of the several Cisco ASA devices I've tried with did I get it to work. Switching to IKEv1, i.e. ISAKMPd, works immediately. / Danial - / Danial -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: Routing issue with VPN tunnel
I don't like responding to my own thread but I really need help with this one, so I'll try to rephrase the question: The remote tunnel endpoint expects traffic originating from a specific ip address - the internal ip of the firewall. How can I achieve this? / Danial On Tue, Dec 9, 2008 at 1:11 PM, do wrote: > Hello, > > I'm having some problems routing traffic through a isakmp > vpn tunnel. > > I have a tunnel successfully set up between my OpenBSD 3.8 > and a Cisco 7200 router. > I'm not good at ascii art, but here's how I see it: > > $int_if = 10.0.0.1 > $remote_host = 192.168.0.1 > > > $int_if <> enc0 <> $ext_if |> (internet) > | |> $remote_gw <--> $remote_host > | > | > $internal_host > > > > There are ACLs on the $remote_gw which only allow traffic > NATed with my $int_if ip. Hence this nat in pf.conf: > nat on enc0 inet from $int_net to $remote_host -> $int_if > > > I've established that the flows exist: > # netstat -rn -f encap > $remote_host/32 0 $int_if/32 0 0 > $remote_gw/50/use/in > $int_if/32 0 $remote_host/32 0 0 > $remote_gw/50/require/out > > # ipsecctl -s flow > flow esp in from $remote_host to $int_if peer $remote_gw > flow esp out from $int_if to $remote_host peer $remote_gw > > > What I CAN do is ping the $remote_host through the tunnel > from the $int_if with the following command: > # ping -I $int_if $remote_host > > This works and replies are received! > > > But if if try pinging from the $internal_host: > c:\> ping $remote_host > > This doesn't work. The packets are not sent through the > tunnel but to the internet. > > > I've tried this route-to line in pf.conf: > pass in log quick on $int_if route-to enc0 from $int_net to > $remote_host keep state > > And by running tcpdump on pflog0 I can see that packets are > matched: > rule 16/(match) pass out on enc0: $int_if > $remote_host: > icmp: echo request > > But no traffic is sent through the tunnel. > > > Why are pings sent from the $internal_host not matched to > the flow/route and sent through the corresponding tunnel? > > Any help is appreciated in resolving this issue! > > > - Danial
Re: Routing issue with VPN tunnel
On Dec 17, 2008 1:14am, Boris Goldberg wrote: > Hello Danial, > > > > Tuesday, December 16, 2008, 6:55:17 PM, you wrote: > > > > DO> This involves the same issue as mentioned earlier, that the > > DO> flows/"dummy tunnel" does in fact get transmitted to the peer for > > DO> quick mode negotiation. > > > > Yes it does, but why do you care? Does the "real" tunnel stop working > > because of that? No it doesn't, but the remote site doesn't accept anything but my specific ip address. So it restricts me from creating additional "broader" flows. I'm gonna try the aforementioned lo1 hack as soon as they allow the new ip I'm gonna use for NAT. / Danial
