On 10/1/18 4:36 PM, Claudio Jeker wrote:
On Mon, Oct 01, 2018 at 04:16:48PM +0100, Kaya Saman wrote:
On 10/1/18 4:12 PM, Janne Johansson wrote:
Den mån 1 okt. 2018 kl 16:56 skrev Kaya Saman <kayasa...@gmail.com
<mailto:kayasa...@gmail.com>>:
Hi,
I've got an issue where something strange is happening with the
routing
table after establishing an ipsec connection.... it's quite hard to
describe but what happens is that the tunnel establishes then routing
goes down completely. The netstat -r command when run on the
router just
hangs and doesn't complete (show any routes).
Perhaps you can't reach your resolver, try running "netstat -rn" to
prevent netstat
from trying to resolve all ips and networks it lists.
--
May the most significant bit of your life be positive.
The resolver is local. However, the issue is deeper as inter-subnet
communications go down and these are ipv4 -> ipv4
If I kill the isakmpd process then communication resumes, as in all layer3+
services start functioning again: icmp, nfs, ssh etc....
Since your policy is from 0.0.0.0/0 to 0.0.0.0/0 all traffic will end up
in the ipsec tunnel. I doubt this is what you want. IPsec flows steal the
traffic before routing happens. I think you need to refine your policy
also check with tcpdump what happens on enc0, etc. pp.
I changed the policy to this:
ike esp transport \
from IP_local to IP_remote main auth hmac-md5 enc \
3des group modp1536 quick auth hmac-md5 enc 3des group none
lifetime 3600 psk "mykey"
Now phase 1 establishes fine but there seems to be an issue negotiating
phase 2.... I have exactly the same thing configured on the other end:
"auth hmac-md5 enc 3des"
When I look at the debug output from the remote box, it uses a "byte
lifetime" attribute in phase 2 when connecting to machines of the same
make - Cisco. Additionally there seems to be some sort of 'proxy'
connection too: 0.0.0.0 to remote / remote to 0.0.0.0
That would probably explain why the "from 0.0.0.0/0 to 0.0.0.0/0" worked
but nothing else does....
On the OpenBSD side in the logs I get this:
isakmpd[93469]: responder_recv_HASH_SA_NONCE: peer proposed invalid
phase 2 IDs: initiator id 0.0.0.0/0.0.0.0, responder id 0.0.0.0/0.0.0.0
isakmpd[93469]: dropped message from <remote_IP> port 500 due to
notification type INVALID_ID_INFORMATION
I have gone through the ipsec.conf man page thoroughly but can't seem to
find any type of setting that would allow for this.
Doing something like:
from 0.0.0.0/0 to 0.0.0.0/0 local {IP} peer {IP} doesn't work either; or
putting the '0.0.0.0/0.0.0.0' field into the srcid and dstid doesn't
work either.....
Checking back years ago, I managed to make it work with the global
0.0.0.0/0 from/to setting but it looks like things have changed since
then maybe?
Perhaps it simply isn't possible to get the two devices to establish
phase 2 due to incompatibility?
