Manual Of The Warrior Of Light Wikipedia
Cripin Plascencia
Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to secure packet exchange over unprotected IP/IPv6 networks such as Internet.
The Internet Key Exchange (IKE) is a protocol that provides authenticated keying material for Internet Security Association and Key Management Protocol (ISAKMP) framework. There are other key exchange schemes that work with ISAKMP, but IKE is the most widely used one. Together they provide means for authentication of hosts and automatic management of security associations (SA).
There is some traffic caught by a policy rule which needs to become encrypted or authenticated, but the policy doesn't have any SAs. The policy notifies IKE daemon about that, and IKE daemon initiates connection to remote host.IKE daemon responds to remote connection.In both cases, peers establish connection and execute 2 phases:
IKE can optionally provide a Perfect Forward Secrecy (PFS), which is a property of key exchanges, that, in turn, means for IKE that compromising the long term phase 1 key will not allow to easily gain access to all IPsec data that is protected by SAs established through this phase 1. It means an additional keying material is generated for each phase 2.
Generation of keying material is computationally very expensive. Exempli gratia, the use of modp8192 group can take several seconds even on very fast computer. It usually takes place once per phase 1 exchange, which happens only once between any host pair and then is kept for long time. PFS adds this expensive operation also to each phase 2 exchange.
Diffie-Hellman (DH) key exchange protocol allows two parties without any initial shared secret to create one securely. The following Modular Exponential (MODP) and Elliptic Curve (EC2N) Diffie-Hellman (also known as "Oakley") Groups are supported:
To avoid problems with IKE packets hit some SPD rule and require to encrypt it with not yet established SA (that this packet perhaps is trying to establish), locally originated packets with UDP source port 500 are not processed with SPD. The same way packets with UDP destination port 500 that are to be delivered locally are not processed in incoming policy check.
AH is a protocol that provides authentication of either all or part of the contents of a datagram through the addition of a header that is calculated based on the values in the datagram. What parts of the datagram are used for the calculation, and the placement of the header, depends whether tunnel or transport mode is used.
The presence of the AH header allows to verify the integrity of the message, but doesn't encrypt it. Thus, AH provides authentication but not privacy. Another protocol (ESP) is considered superior, it provides data privacy and also its own authentication method.
In transport mode AH header is inserted after IP header. IP data and header is used to calculate authentication value. IP fields that might change during transit, like TTL and hop count, are set to zero values before authentication.
In transport mode ESP header is inserted after original IP header. ESP trailer and authentication value is added to the end of the packet. In this mode only IP payload is encrypted and authenticated, IP header is not secured.
IPsec throughput results of various encryption and hash algorithm combinations are published on MikroTik products page. When testing throughput, please follow the guidelines available in the Traffic Generator manual page
Peer configuration settings are used to establish connections between IKE daemons. This connection then will be used to negotiate keys and algorithms for SAs. Exchange mode is the only unique identifier between the peers, meaning that there can be multiple peer configurations with the same remote-address as long as different exchange-mode is used.
Currently only packets with source address of 192.168.77.254/32 will match the IPsec policies. For local network to be able to reach remote subnets, it is necessary to change the source address of local hosts to the dynamically assigned mode config IP address. It is possible to generate source NAT rules dynamically. This can be done by creating a new address list which contains of all local networks that NAT rule should be applied. In our case, it is 192.168.88.0/24.
There are some scenarios where for security reasons you would like to drop access from/to specific networks if incoming/outgoing packets are not encrypted. For example, if we have L2TP/IPsec setup we would want to drop non encrypted L2TP connection attempts.
IPsec policy matcher takes two parameters direction,policy. We used incoming direction and IPsec policy. IPsec policy option allows us to inspect packets after decapsulation, so for example if we want to allow only gre encapsulated packet from specific source address and drop the rest we could set up following rules:
Now router will drop any L2TP unencrypted incoming traffic, but after successful L2TP/IPsec connection dynamic policy is created with higher priority than it is on default static rule and packets matching that dynamic rule can be forwarded.
IPsec, as any other service in RouterOS, uses main routing table regardless what local-address parameter is used for Peer configuration. It is necessary to apply routing marks to both IKE and IPSec traffic.
Currently, we see "phase1 negotiation failed due to time up" errors in the log. It is because IPsec tries to reach the remote peer using the main routing table with incorrect source address. It is necessary to mark UDP/500, UDP/4500 and ipsec-esp packets using Mangle.
Consider the following example. There are multiple IP addresses from the same subnet on the public interface. Masquerade rule is configured on out-interface. It is necessary to use one of the IP addresses explicitly.
Currently the phase 1 connection uses a different source address than we specified and "phase1 negotiation failed due to time up" errors are shown in the logs. This is because masquerade is changing the source address of the connection to match pref-src address of the connected route. Solution is to exclude connections from the public IP address from being masqueraded.
Consider setup as illustrated below. Two remote office routers are connected to internet and office workstations are behind NAT. Each office has its own local subnet, 10.1.202.0/24 for Office1 and 10.1.101.0/24 for Office2. Both remote offices needs secure tunnel to local networks behind routers.
Start off by creating new Phase 1 profile and Phase 2 proposal entries using stronger or weaker encryption parameters that suits your needs. It is advised to create separate entries for each menu so that they are unique for each peer in case it is necessary to adjust any of the settings in the future. These parameters must match between the sites or else the connection will not establish.
Continue by configuring a peer. Specify the address of the remote router. This address should be reachable through UDP/500 and UDP/4500 ports, so make sure appropriate actions are taken regarding the router's firewall. Specify the name for this peer as well as the newly created profile.
At this point if you try to send traffic over the IPsec tunnel, it will not work, packets will be lost. This is because both routers have NAT rules (masquerade) that is changing source address before packet is encrypted. Router is unable to encrypt the packet, because source address do not match address specified in policy configuration. For more information see IPsec packet flow example.
Before configuring IPsec, it is required to set up certificates. It is possible to use a separate Certificate Authority for certificate management, however in this example, self signed certificates are generated in RouterOS System/Certificates menu. Some certificate requirements should be met to connect various devices to the server:
Identity menu allows to match specific remote peers and assign different configuration for each one of them. First, create a default identity, that will accept all peers, but will verify the peer's identity with its certificate.
For example, we want to assign different mode config for user "A", who uses certificate "rw-client1" to authenticate itself to the server. First of all, make sure a new mode config is created and ready to be applied for the specific user.
Split tunneling is a method which allows road warrior clients to only access a specific secured network and at the same time send the rest of the traffic based on their internal routing table (as opposed to sending all traffic over the tunnel). To configure split tunneling, changes to mode config parameters are needed.
It is also possible to send specific DNS server for the client to use. By default system-dns=yes is used, which sends DNS servers that are configured on the router itself in IP/DNS. We can force the client to use different DNS server by using the static-dns parameter.
While it is possible to adjust IPsec policy template to only allow road warrior clients to generate policies to network configured by split-include parameter, this can cause compatibility issues with different vendor implementations (see known limitations). Instead of adjusting the policy template, allow access to secured network in IP/Firewall/Filter and drop everything else.
While it is possible to use the default policy template for policy generation, it is better to create a new policy group and template to separate this configuration from any other IPsec configuration.
If we look at the generated dynamic policies, we see that only traffic with a specific (received by mode config) source address will be sent through the tunnel. But a router in most cases will need to route a specific device or network through the tunnel. In such case we can use source NAT to change the source address of packets to match the mode config address. Since the mode config address is dynamic, it is impossible to create static source NAT rule. In RouterOS it is possible to generate dynamic source NAT rules for mode config clients.
c80f0f1006