On 05/03/2016 10:23 PM, kasak wrote:
Hello everybody. I hope somebody can help me with iked.
I have 2 gates, both can ping each other. One has this iked.conf:
ikev2 from 212.233.112.10 to 192.168.1.0/24 \
from 192.168.2.0/23 to 192.168.1.0/24 \
local 212.233.112.10 srcid 212.233.112.10
Another has:
ikev2 active \
from 77.220.137.168 to 192.168.2.0/23 \
from 192.168.1.0/24 to 192.168.2.0/23 \
peer 212.233.112.10 srcid 77.220.137.168
And the problem is: local lan clients can reach remote lan, but local
gate itself cannot reach. Look:
$ ping -c 2 -I 192.168.2.10 192.168.1.240
PING 192.168.1.240 (192.168.1.240): 56 data bytes
64 bytes from 192.168.1.240: icmp_seq=0 ttl=63 time=2.987 ms
64 bytes from 192.168.1.240: icmp_seq=1 ttl=63 time=2.243 ms
--- 192.168.1.240 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
but
$ ping -c 2 192.168.1.240
PING 192.168.1.240 (192.168.1.240): 56 data bytes
--- 192.168.1.240 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
Please check with tcpdump on the enc0 interface what kind of traffic is
sent when doing the ping.
# tcpdump -nvi enc0 icmp
Both ping commands sent from same gate.
Here is ipsecctl -sa from one of gates:
FLOWS:
flow esp in from 192.168.1.0/24 to 212.233.112.10 peer 77.220.137.168
srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type use
flow esp out from 212.233.112.10 to 192.168.1.0/24 peer 77.220.137.168
srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type require
flow esp in from 192.168.1.0/24 to 192.168.2.0/23 peer 77.220.137.168
srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type use
flow esp out from 192.168.2.0/23 to 192.168.1.0/24 peer 77.220.137.168
srcid IPV4/212.233.112.10 dstid IPV4/77.220.137.168 type require
flow esp out from ::/0 to ::/0 type deny
SAD:
esp tunnel from 212.233.112.10 to 77.220.137.168 spi 0x22dd1b34 auth
hmac-sha2-256 enc aes-256
esp tunnel from 77.220.137.168 to 212.233.112.10 spi 0xd1abf711 auth
hmac-sha2-256 enc aes-256
I have the same issue on my boxes that has to contact remote networks.
I've solved this by translating my outgoing
traffic from my gateway over ipsec to the remote network to a internal
interface. See example below.
/etc/pf.conf:
...
match out log on enc0 from (egress) to 10.10.0.0/24 nat-to (em2) # where
em2 is my LAN interface
...
