Hi,
i'm a absolutly IP Sec noob, but have to install a site2site connection from my mikrotik to a juniper.
We need to access a specified ip/port on the remote site.
The IPSEC Connection seems to be up, but i'm unable to access the other side.
I guess i need a additional route, for our LAN to access on the other side (or something like this).
May could you check my config?
this is what we got from "the other side":
Supplier: Juniper
Type: SRX
Model: 340
OS: Junos: 15.1X49-D50.3
Public IP Peer address: 193.123.456.145
IKE Proposal Prameters
Authentication Mode: Preshared keys
Preshared Key: mysecret
Authentication Algorithm: SHA1
Encryption Algorithm: AES256
Diffie-Hellman Group: Group 5
Time Lifetime: 86400
Very cool, thank you!
i set the PFS-Group to “none”
but i still see this:
20:26:54 ipsec processing payloads: NOTIFY
20:26:54 ipsec notify: NAT_DETECTION_SOURCE_IP
20:26:54 ipsec notify: NAT_DETECTION_DESTINATION_IP 20:26:54 ipsec notify: unknown 40002
→ “unknown 40002” isnt very specific :-/
I don’t like this part of your configuration export:
/ip ipsec policy set 0 dst-address=192.168.1.33/32 src-address=192.168.0.0/24
The thing is that if set is used in RouterOS configuration export, it always means a modification of parameters of some element in the configuration which exists by default. In the particular case of the /ip ipsec policy table, the only element which exists by default is a default policy template. Policy templates are used when the actual policy has to be generated dynamically. But your only /ip ipsec identity row doesn’t ask for dynamic policy generation. If no policy is linked to a peer and the identity row doesn’t order that a policy was generated, RouterOS automatically generates a transport mode policy with local peer’s own address as src-address and remote peer’s address as dst-address and asks the remote peer for such a policy; as the Juniper side configuration doesn’t foresee such one, it responds with TS_UNACCEPTABLE. (TS = Traffic Selector, a tuple of source and destination addresses, and optionally IP protocol and ports to be diverted to the Security Association constituted by the policy).
So you have to add the policy rather than modifying the default template: /ip ipsec policy add dst-address=192.168.1.33/32 src-address=192.168.0.0/24 tunnel=yes peer=vpn
To reset the default template to its original values, you can use /ip ipsec policy set 0 src-address=::/0 dst-address=::/0, but it is not mandatory to make the connection to the Juniper work.
thanks a lot for our explanaition!
i resetted the default value and added a new one.
i also found a missconfiguration in my proposal (sha1 instead of sha256).
# ID STATE UPTIME PH2-TOTAL REMOTE-ADDRESS
0 193.123.456.145 established 9m19s 1 193.123.456.145
but i cant ping the ip address on the other end, and a traceroute (/tool traceroute 192.168.1.33) routes through my default gateway, not though the ipsec connection.
do i need a route for that?
i read something about srcnat, but i guess this is the wrong way..
0 chain=srcnat action=accept src-address=192.168.0.0/24 dst-address=192.168.1.33 log=no log-prefix=“”
1 chain=srcnat action=masquerade log=no log-prefix=“”
All firewall processing, including NAT, takes place before the outgoing packets are matched to the traffic selectors of IPsec policies. Since the regular routing finds a route via some interface, the packets get src-nat’ed to the address of that interface thanks to the rule 1 above.
To avoid this for the packets from 192.168.0.0/24 to 192.168.1.33 from getting src-nat’ed and thus getting missed by the traffic selector, either the rule 0 above is required, or an action=notrack src-address=192.168.0.0/24 dst-address=192.168.1.33 in chain prerouting of /ip firewall raw - both have the same effect, packets from 192.168.0.0/24 to 192.168.1.33 do not get src-nat’ed.
But the above is not sufficient when pinging/tracerouting from the router itself, as in that case, another thing comes into play - the source address of packets sent by the router itself is chosen up to the route found by the regular routing. Since you (probably) have only the default route via WAN and the routes to local subnets, when pinging an address which is not in a connected subnet, the route via WAN is chosen, and therefore the WAN IP is used as source one. Packets with that source address don’t match the policy’s traffic selector, so they don’t get intercepted by the policy.
So if you don’t need that the router itself talks to 192.168.1.33 during normal operation, it is enough to add src-address=192.168.0.x (router’s own IP address in 192.168.0.0/24) to the ping or traceroute parameter list. If you do, there are two ways - either add a dedicated route to 192.168.1.33/32, via any gateway, with pref-src=192.168.0.x, or add a rule src-address-type=local dst-address=192.168.1.33 action=src-nat to-addresses=192.168.0.x to chain srcnat of /ip firewall nat - even before rule 0 above if it is present, and definitely before rule 1.
Thanks a lot for your help and great explanation!
Everything makes absolulty sense to me - so i changed the things you said, and everything is working now as expected
