Hi,
I have open ports (47, 500, 4500, esp) for my GRE IPSEC tunnels on my firewall, is any way to forward these port at the same time for a customer router which is behind one of my ether port (customer also need to have their gre ipsec tunnels)?
500 and 4500 are UDP port numbers. 47 and 50 are IP protocol numbers of GRE and ESP, respectively, so a different field in the packet header and a different parameter of firewall rules. You can refer to them by names (protocol=gre, protocol=ipsec-esp).
If the customer’s router has its own public IP address, there is no need to “forward” (using chain dstnat of /ip firewall nat) the protocols or ports to it, it is enough not to block them in the forward chain of /ip firewall filter.
If the customer’s router does not have its own public IP and its connections are NATed behind your own public IP, and both routers need to accept incoming IPsec connections, a solution is possible but it is a bit complicated.
Regarding GRE, I suppose we discuss IPsec-encapsulated GRE here; if not, it is not possible to have GRE wide-open for both you and the customer simultaneously; for one of the routers, GRE has to be dst-nated (or exempted from dst-nat) depending on the remote address of each individual GRE peer for one of the routers, whereas the other router will get “the rest”.
So which case(s) are we talking about?
I tell you how I configured this, I have on my WAN 5 more routable Public IP, so I pick-up one of these and did port forward to customer Fortigate router that is located behind my ether7 port
22 ;;; FGT
chain=dstnat action=dst-nat to-addresses=10.x.x.2 protocol=udp dst-address=MIKROTIK-PublicIP2 dst-port=500 log=no log-prefix="FGT"
23 ;;; FGT
chain=dstnat action=dst-nat to-addresses=10.x.x.2 protocol=ipsec-esp dst-address=MIKROTIK-PublicIP2 log=no log-prefix="FGT"
24 ;;; FGT
chain=dstnat action=dst-nat to-addresses=10.x.x.2 protocol=udp dst-address=MIKROTIK-PublicIP2 dst-port=4500 log=no log-prefix="FGT"
Now at customer Fortigate we are trying to create Gre Ipsec Tunnels but I’m struggling with this http://forum.mikrotik.com/t/gre-ipsec-between-mikrotik-and-fortigate/147446/4
Remote Gre Side to fortigate is trying to connect not to PublicIP2 (in front of FGT, but on main PublicIP), no matter that configuration of ipsec is to use PublicIP2.
Enad at the end it give error that there’s not IKEv2 peer config for this PubliIP1.
11:37:24 ipsec ike2 init retransmit
11:37:24 ipsec,debug ===== sending 300 bytes from MIKROTIK-Gre-WAN[500] to MIKROTIK-PublicIP2-InfrontOf-FGT[500]
11:37:24 ipsec,debug 1 times of 300 bytes message will be sent to MIKROTIK-PublicIP2-InfrontOf-FGT[500]
11:37:26 ipsec,debug ===== received 316 bytes from MIKROTIK-PublicIP1-InfrontOf-FGT[500] to MIKROTIK-Gre-WAN[500]
11:37:26 ipsec -> ike2 request, exchange: SA_INIT:0 MIKROTIK-PublicIP1-InfrontOf-FGT[500]
11:37:26 ipsec no IKEv2 peer config for MIKROTIK-PublicIP1-InfrontOf-FGT
11:37:29 ipsec,debug ===== received 316 bytes from MIKROTIK-PublicIP1-InfrontOf-FGT[500] to MIKROTIK-Gre-WAN[500]
11:37:29 ipsec -> ike2 request, exchange: SA_INIT:0 MIKROTIK-PublicIP1-InfrontOf-FGT[500]
11:37:29 ipsec no IKEv2 peer config for MIKROTIK-PublicIP1-InfrontOf-FGT
I’m guessing you need appropriate src-nat in addition to dst-nat.
I did:
;;; FGT - src-nat to MIKROTIK-PublicIP2-InfrontOf-FGT
chain=srcnat action=src-nat to-addresses=MIKROTIK-PublicIP2-InfrontOf-FGT src-address=10.x.x.2 log=no log-prefix=""
when I log in to Fortigate device, on dashboard I see that my wan address is “MIKROTIK-PublicIP2-InfrontOf-FGT” so src-nat is working.
There is one caveat - the srcnat and dstnat rule chains are only used when handling an initial packet of a connection, the rest of packets belonging to that connection inherits the src-nat and/or dst-nat handling ordered by the rules handling the initial one.
So if the remote Mikrotik started trying to connect to the public IP representing the Fortigate before you have set the dst-nat rule, and keeps re-trying ever since, the packets from the remote Mikrotik land in chain input of the local one and never reach the Fortinet.
If it is the case, one possibility is to disable the IPsec peer at the remote Mikrotik for at least three minutes, a faster one is to remove the connection from the connection tracking list:
/ip firewall connection remove [find protocol=udp dst-address~“MIKROTIK-PublicIP2-InfrontOf-FGT”]
If the src-nat rule changing the source address from 10.x.x.2 to MIKROTIK-PublicIP2-InfrontOf-FGT was not there before the Fortigate started attempting to connect, the consequence is the same: the first packet from the Fortigate hit the default src-nat or masquerade rule substituting that connection’s source address by MIKROTIK-PublicIP1-InfrontOf-FGT. So do
/ip firewall connection remove [find protocol=udp src-address~“10.x.x.2”]
Just for the case, the selective src-nat rule for 10.x.x.2 must be before the generic one in the srcnat chain.
ok I did this, but problem was not here, I removed this settings from Fortigate Phase1:
set local-gw x.x.x.85 (where this ip is PublicIP2 of Mikrotik in front of FGT)
after that my Phase1 with remote Gre Ipsec is established 
Now I have problem because Phase2 in transport mode won’t go up.
( x.x.x.85 - PublicIP2 in front of FGT, x.x.x.122 - Remote Mikrotik to wich FGT is connecting, 10.x.x.2 - internal wan address of FGT behind Mikrotik)
Mikrotik log:
14:38:11 ipsec,debug KA: x.x.x.122[4500]->x.x.x.85[4500]
14:38:11 ipsec,debug 1 times of 1 bytes message will be sent to x.x.x.85[4500]
14:38:17 ipsec,debug ===== received 352 bytes from x.x.x.85[4500] to x.x.x.122[4500]
14:38:17 ipsec -> ike2 request, exchange: CREATE_CHILD_SA:175 x.x.x.85[4500]
14:38:17 ipsec payload seen: ENC
14:38:17 ipsec processing payload: ENC
14:38:17 ipsec,debug => iv (size 0x10)
14:38:17 ipsec,debug 5667825e d6188ec3 5bea68c8 dde90777
14:38:17 ipsec,debug => plain payload (trimmed) (first 0x100 of 0x110)
14:38:17 ipsec,debug 2100000c 03044007 e38a7ff0 28000034 00000030 01030404 e38a7ff0 0300000c
14:38:17 ipsec,debug 0100000c 800e0100 03000008 0300000c 03000008 04000015 00000008 05000000
14:38:17 ipsec,debug 22000014 187b91b7 e77f1db2 baab97d5 10ed5f07 2c00008c 00150000 019a2ef5
14:38:17 ipsec,debug 7a333945 7228286a cfe2e86d b8337e0b a621b2fd 83cb02dc df6c2575 17f0881d
14:38:17 ipsec,debug b9d3e3fe 8c458f35 38a933f7 868bdff8 346b48ed 73d08116 112ff237 2715009b
14:38:17 ipsec,debug 8acaebf0 59f860d2 90399176 90139906 4673ba06 78150417 3e4d9679 604d7917
14:38:17 ipsec,debug 8aacf4a9 c36ddc80 4aff69f5 aa2fd369 f1c41c9b 710921a6 7b588fea dc06e336
14:38:17 ipsec,debug 2d000018 01000000 072f0010 0000ffff 0a1e0002 0a1e0002 00000018 01000000
14:38:17 ipsec,debug decrypted
14:38:17 ipsec payload seen: NOTIFY
14:38:17 ipsec payload seen: SA
14:38:17 ipsec payload seen: NONCE
14:38:17 ipsec payload seen: KE
14:38:17 ipsec payload seen: TS_I
14:38:17 ipsec payload seen: TS_R
14:38:17 ipsec create child: respond
14:38:17 ipsec processing payload: NONCE
14:38:17 ipsec processing payloads: NOTIFY
14:38:17 ipsec notify: USE_TRANSPORT_MODE
14:38:17 ipsec processing payloads: NOTIFY
14:38:17 ipsec notify: USE_TRANSPORT_MODE
14:38:17 ipsec peer wants transport mode
14:38:17 ipsec processing payload: CONFIG (not found)
14:38:17 ipsec processing payload: TS_I
14:38:17 ipsec 10.x.x.2 ip-proto:47
14:38:17 ipsec processing payload: TS_R
14:38:17 ipsec x.x.x.122 ip-proto:47
14:38:17 ipsec NAT in transport mode, using visible addresses
14:38:17 ipsec canditate selectors: x.x.x.122 ip-proto:47 <=> x.x.x.85:4500 ip-proto:47
14:38:17 ipsec processing payload: SA
14:38:17 ipsec IKE Protocol: ESP
14:38:17 ipsec proposal #1
14:38:17 ipsec enc: aes256-cbc
14:38:17 ipsec auth: sha256
14:38:17 ipsec dh: ecp521
14:38:17 ipsec searching for policy for selector: x.x.x.122 ip-proto:47 <=> x.x.x.85:4500 ip-proto:47
14:38:17 ipsec recorded wild match: x.x.x.122 <=> x.x.x.85
14:38:17 ipsec matched proposal:
14:38:17 ipsec proposal #1
14:38:17 ipsec enc: aes256-cbc
14:38:17 ipsec auth: sha256
14:38:17 ipsec dh: ecp521
14:38:17 ipsec processing payload: KE
14:38:17 ipsec,debug => shared secret (size 0x42)
14:38:17 ipsec,debug 00a9af20 3d2836ef f603e74c 72b101a3 bff68d3c bd8cc4e7 ccbcfb76 acff5138
14:38:17 ipsec,debug 161fc903 e1ebcc33 94b75306 bc5dca8d 37d2f463 236ebde6 b5457d59 ed6c2f64
14:38:17 ipsec,debug c6ba
14:38:17 ipsec create child: finish
14:38:17 ipsec adding payload: NONCE
14:38:17 ipsec,debug => (size 0x1c)
14:38:17 ipsec,debug 0000001c 6ec07bc9 ab4e2dfc 81a68613 a0a4bea7 8581ed59 6a33c227
14:38:17 ipsec adding payload: KE
14:38:17 ipsec,debug => (size 0x8c)
14:38:17 ipsec,debug 0000008c 00150000 0035156b 8738c0e7 356bc8a5 90a32984 3c722fe2 0b01b99e
14:38:17 ipsec,debug 65c135e1 74e53042 9ccf843b 0d720310 8952fb0b 80b99649 eabfa7b9 a12fc567
14:38:17 ipsec,debug c27d2215 d7da1494 05ef00ce a3d523ba 28ea400c c574f7a1 6e68eb61 25b453ab
14:38:17 ipsec,debug 4e15d672 daeb50dd 4d4ee64b 834b13bd 6e3cac69 3e501882 44d0f2ee 83a3a143
14:38:17 ipsec,debug a5795631 96258702 05926deb
14:38:17 ipsec initiator selector: x.x.x.85:4500 ip-proto:47
14:38:17 ipsec adding payload: TS_I
14:38:17 ipsec,debug => (size 0x18)
14:38:17 ipsec,debug 00000018 01000000 072f0010 11941194 d9619a55 d9619a55
14:38:17 ipsec responder selector: x.x.x.122 ip-proto:47
14:38:17 ipsec adding payload: TS_R
14:38:17 ipsec,debug => (size 0x18)
14:38:17 ipsec,debug 00000018 01000000 072f0010 0000ffff 5036f67a 5036f67a
14:38:17 ipsec adding payload: SA
14:38:17 ipsec,debug => (size 0x34)
14:38:17 ipsec,debug 00000034 00000030 01030404 0d6ea61a 0300000c 0100000c 800e0100 03000008
14:38:17 ipsec,debug 0300000c 03000008 04000015 00000008 05000000
14:38:17 ipsec adding notify: USE_TRANSPORT_MODE
14:38:17 ipsec,debug => (size 0x8)
14:38:17 ipsec,debug 00000008 00004007
14:38:17 ipsec <- ike2 reply, exchange: CREATE_CHILD_SA:175 x.x.x.85[4500]
14:38:17 ipsec,debug ===== sending 448 bytes from x.x.x.122[4500] to x.x.x.85[4500]
14:38:17 ipsec,debug 1 times of 452 bytes message will be sent to x.x.x.85[4500]
14:38:17 ipsec,debug => child keymat (size 0x80)
14:38:17 ipsec,debug f71904c5 da978a14 521bf57d b5eeaeea e5d253d1 7be33e52 43dd7fbf 134bc711
14:38:17 ipsec,debug cfd95d0c a3c6069a dafa830b c42deb88 97d32055 449db11c 323ab64e f758f7b6
14:38:17 ipsec,debug d661fab4 592a88a1 fdd77aa2 cd4d383c b2468a45 414060e1 8c7cd9f7 fbf91fbb
14:38:17 ipsec,debug b747ece7 d0ae26d1 4b730ccf 9c66bad8 28a25c97 dfed3124 89a9fc41 1330fc0b
14:38:17 ipsec IPsec-SA established: x.x.x.85[4500]->x.x.x.122[4500] spi=0xd6ea61a
14:38:17 ipsec IPsec-SA established: x.x.x.122[4500]->x.x.x.85[4500] spi=0xe38a7ff0
14:38:17 ipsec,debug ===== received 80 bytes from x.x.x.85[4500] to x.x.x.122[4500]
14:38:17 ipsec -> ike2 request, exchange: INFORMATIONAL:176 x.x.x.85[4500]
14:38:17 ipsec payload seen: ENC
14:38:17 ipsec processing payload: ENC
14:38:17 ipsec,debug => iv (size 0x10)
14:38:17 ipsec,debug d99e2bb8 4ab99b1f c2b35aa1 3df42f93
14:38:17 ipsec,debug => plain payload (trimmed) (size 0xc)
14:38:17 ipsec,debug 0000000c 03040001 e38a7fec
14:38:17 ipsec,debug decrypted
14:38:17 ipsec payload seen: DELETE
14:38:17 ipsec respond: info
14:38:17 ipsec processing payloads: NOTIFY (none found)
14:38:17 ipsec processing payloads: DELETE
14:38:17 ipsec delete ESP SA
14:38:17 ipsec delete spi: 0xe38a7fec
14:38:17 ipsec IPsec-SA killing: x.x.x.85[4500]->x.x.x.122[4500] spi=0xa430a85
14:38:17 ipsec IPsec-SA killing: x.x.x.122[4500]->x.x.x.85[4500] spi=0xe38a7fec