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 <kayasaman@gmail.com
>>> <mailto:kayasaman@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?
No comments:
Post a Comment