EoIP Tunnel that doesn't want to tunnel
Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker
Hi Christopher, Based on the fact that you get 2 pings through before it fails, I suspect that the route to the remote end of the EoIP tunnel changes, most likely to be going over the tunnel itself. Since the tunnel can't be established via itself, it then drops. You may need to add in a static route for the single IP address that is the remote end of the tunnel to ensure it always takes the "underlay" path. Regards, Philip Loenneker| Senior Network Engineer TasmaNet | Vastnet | Netmode -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Christopher Hawker Sent: Monday, 6 September 2021 9:01 AM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftalk.mikrot...
Hi, Another posibility Given it has ipsec, you likely also need to allow that in the firewall. And once working, preferably disallow unencrypted protocol GRE coming in, or leaving. (It could be the 2 packets come through unencrypted, before ipsec comes up, you don't want that) ie. Allow UDP 500 in (from remote IP only?) Allow protocol ESP in (from remote IP only?) ** Assumes no NAT ** Maybe allow UDP 4500 in (In case there is some NAT) Later: (I think these to allow the GRE in/out but only if has been processed via ipsec) Allow protocol GRE in if it has ipsec-policy=in, ipsec Allow protocol GRE out if it has ipsec-policy=out,ipsec (Probably redundant) ** Ideally ** Drop protocol GRE out if doesn't have ipsec-policy=out,ipsec Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Sun, 5 Sep 2021 23:01:08 +0000 Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
Hi Roger, I've established that GRE itself unencrypted works as expected, however with IPSec enabled it does not. Logs also show "phase 1 negotiation failed due to time up", however I've disabled the Input chain drop rules on both routers, just to confirm if it was a firewall issue, which it is not. Something else is going on... Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Roger Plant <rplant@melbpc.org.au> Sent: Monday, September 6, 2021 9:56 AM To: public@talk.mikrotik.com.au <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi, Another posibility Given it has ipsec, you likely also need to allow that in the firewall. And once working, preferably disallow unencrypted protocol GRE coming in, or leaving. (It could be the 2 packets come through unencrypted, before ipsec comes up, you don't want that) ie. Allow UDP 500 in (from remote IP only?) Allow protocol ESP in (from remote IP only?) ** Assumes no NAT ** Maybe allow UDP 4500 in (In case there is some NAT) Later: (I think these to allow the GRE in/out but only if has been processed via ipsec) Allow protocol GRE in if it has ipsec-policy=in, ipsec Allow protocol GRE out if it has ipsec-policy=out,ipsec (Probably redundant) ** Ideally ** Drop protocol GRE out if doesn't have ipsec-policy=out,ipsec Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Sun, 5 Sep 2021 23:01:08 +0000 Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi,
Something else is going on... Then look at your IPSEC config. Do the default proposals match on both routers? Are the default /0 policies enabled on both ends?
Turn on ipsec logging, that will give you a wealth of info. Also: I presume you just made up the public IP's because you were posting in a public forum on a device that you had said you have removed all firewall rules from? Or are these the real IP? Or are both these devices behind CGNAT? https://www.lookip.net/whois/192.0.2.10 Comment: Addresses starting with "192.0.2.", "198.51.100.", or "203.0.113." are reserved for use in documentation and sample configurations. They should never be used in a live network configuration. No one has permission to use these addresses on the Internet. Andy -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Christopher Hawker Sent: Monday, 6 September 2021 8:02 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi Roger, I've established that GRE itself unencrypted works as expected, however with IPSec enabled it does not. Logs also show "phase 1 negotiation failed due to time up", however I've disabled the Input chain drop rules on both routers, just to confirm if it was a firewall issue, which it is not. Something else is going on... Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Roger Plant <rplant@melbpc.org.au> Sent: Monday, September 6, 2021 9:56 AM To: public@talk.mikrotik.com.au <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi, Another posibility Given it has ipsec, you likely also need to allow that in the firewall. And once working, preferably disallow unencrypted protocol GRE coming in, or leaving. (It could be the 2 packets come through unencrypted, before ipsec comes up, you don't want that) ie. Allow UDP 500 in (from remote IP only?) Allow protocol ESP in (from remote IP only?) ** Assumes no NAT ** Maybe allow UDP 4500 in (In case there is some NAT) Later: (I think these to allow the GRE in/out but only if has been processed via ipsec) Allow protocol GRE in if it has ipsec-policy=in, ipsec Allow protocol GRE out if it has ipsec-policy=out,ipsec (Probably redundant) ** Ideally ** Drop protocol GRE out if doesn't have ipsec-policy=out,ipsec Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Sun, 5 Sep 2021 23:01:08 +0000 Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
To my knowledge, IPsec config for EoIP is handled by the config window for the interface. There was no advanced config, all I did was enter the secret in the interface window. As far as I know, IPsec for EoIP tunnels isnlt configured in "IP > IPsec". I intentionally changed the IP addresses to use RFC5737 addresses due to these messages being publicly available. Don't worry, the devices do have proper publicly routable addresses. Would have done this anyway regardless of the firewall status. Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Andrew Oakeley <andrew@oakeley.com.au> Sent: Monday, September 6, 2021 10:15 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi,
Something else is going on... Then look at your IPSEC config. Do the default proposals match on both routers? Are the default /0 policies enabled on both ends?
Turn on ipsec logging, that will give you a wealth of info. Also: I presume you just made up the public IP's because you were posting in a public forum on a device that you had said you have removed all firewall rules from? Or are these the real IP? Or are both these devices behind CGNAT? https://www.lookip.net/whois/192.0.2.10 Comment: Addresses starting with "192.0.2.", "198.51.100.", or "203.0.113." are reserved for use in documentation and sample configurations. They should never be used in a live network configuration. No one has permission to use these addresses on the Internet. Andy -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Christopher Hawker Sent: Monday, 6 September 2021 8:02 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi Roger, I've established that GRE itself unencrypted works as expected, however with IPSec enabled it does not. Logs also show "phase 1 negotiation failed due to time up", however I've disabled the Input chain drop rules on both routers, just to confirm if it was a firewall issue, which it is not. Something else is going on... Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Roger Plant <rplant@melbpc.org.au> Sent: Monday, September 6, 2021 9:56 AM To: public@talk.mikrotik.com.au <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi, Another posibility Given it has ipsec, you likely also need to allow that in the firewall. And once working, preferably disallow unencrypted protocol GRE coming in, or leaving. (It could be the 2 packets come through unencrypted, before ipsec comes up, you don't want that) ie. Allow UDP 500 in (from remote IP only?) Allow protocol ESP in (from remote IP only?) ** Assumes no NAT ** Maybe allow UDP 4500 in (In case there is some NAT) Later: (I think these to allow the GRE in/out but only if has been processed via ipsec) Allow protocol GRE in if it has ipsec-policy=in, ipsec Allow protocol GRE out if it has ipsec-policy=out,ipsec (Probably redundant) ** Ideally ** Drop protocol GRE out if doesn't have ipsec-policy=out,ipsec Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Sun, 5 Sep 2021 23:01:08 +0000 Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi,
As far as I know, IPsec for EoIP tunnels isnlt configured in "IP > IPsec". Yes and no..... it still uses the info from here even though you don't configure it specifically. So the default proposals need to match and the /0 <-> /0 policy needs to be enabled. When the tunnel comes up you will see it as a dynamic tunnel in IP-IPSEC.
I intentionally changed the IP addresses to use RFC5737 Thought as much... but just cheking....
Andrew -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Christopher Hawker Sent: Monday, 6 September 2021 8:24 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel To my knowledge, IPsec config for EoIP is handled by the config window for the interface. There was no advanced config, all I did was enter the secret in the interface window. As far as I know, IPsec for EoIP tunnels isnlt configured in "IP > IPsec". I intentionally changed the IP addresses to use RFC5737 addresses due to these messages being publicly available. Don't worry, the devices do have proper publicly routable addresses. Would have done this anyway regardless of the firewall status. Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Andrew Oakeley <andrew@oakeley.com.au> Sent: Monday, September 6, 2021 10:15 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi,
Something else is going on... Then look at your IPSEC config. Do the default proposals match on both routers? Are the default /0 policies enabled on both ends?
Turn on ipsec logging, that will give you a wealth of info. Also: I presume you just made up the public IP's because you were posting in a public forum on a device that you had said you have removed all firewall rules from? Or are these the real IP? Or are both these devices behind CGNAT? https://www.lookip.net/whois/192.0.2.10 Comment: Addresses starting with "192.0.2.", "198.51.100.", or "203.0.113." are reserved for use in documentation and sample configurations. They should never be used in a live network configuration. No one has permission to use these addresses on the Internet. Andy -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Christopher Hawker Sent: Monday, 6 September 2021 8:02 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi Roger, I've established that GRE itself unencrypted works as expected, however with IPSec enabled it does not. Logs also show "phase 1 negotiation failed due to time up", however I've disabled the Input chain drop rules on both routers, just to confirm if it was a firewall issue, which it is not. Something else is going on... Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Roger Plant <rplant@melbpc.org.au> Sent: Monday, September 6, 2021 9:56 AM To: public@talk.mikrotik.com.au <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi, Another posibility Given it has ipsec, you likely also need to allow that in the firewall. And once working, preferably disallow unencrypted protocol GRE coming in, or leaving. (It could be the 2 packets come through unencrypted, before ipsec comes up, you don't want that) ie. Allow UDP 500 in (from remote IP only?) Allow protocol ESP in (from remote IP only?) ** Assumes no NAT ** Maybe allow UDP 4500 in (In case there is some NAT) Later: (I think these to allow the GRE in/out but only if has been processed via ipsec) Allow protocol GRE in if it has ipsec-policy=in, ipsec Allow protocol GRE out if it has ipsec-policy=out,ipsec (Probably redundant) ** Ideally ** Drop protocol GRE out if doesn't have ipsec-policy=out,ipsec Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Sun, 5 Sep 2021 23:01:08 +0000 Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi Christopher, Perhaps add a system/ logging rule of ipsec and !packet and see if the additional log tells you anything. You can also look at the various ip/ ipsec tabs, and make sure the entry for your gre tunnel looks similar/symmetric at both ends. Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Mon, 6 Sep 2021 00:01:35 +0000 Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Roger, I've established that GRE itself unencrypted works as expected, however with IPSec enabled it does not. Logs also show "phase 1 negotiation failed due to time up", however I've disabled the Input chain drop rules on both routers, just to confirm if it was a firewall issue, which it is not. Something else is going on... Thanks, Christopher Hawker ________________________________ From: Public <public-bounces@talk.mikrotik.com.au> on behalf of Roger Plant <rplant@melbpc.org.au> Sent: Monday, September 6, 2021 9:56 AM To: public@talk.mikrotik.com.au <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Hi, Another posibility Given it has ipsec, you likely also need to allow that in the firewall. And once working, preferably disallow unencrypted protocol GRE coming in, or leaving. (It could be the 2 packets come through unencrypted, before ipsec comes up, you don't want that) ie. Allow UDP 500 in (from remote IP only?) Allow protocol ESP in (from remote IP only?) ** Assumes no NAT ** Maybe allow UDP 4500 in (In case there is some NAT) Later: (I think these to allow the GRE in/out but only if has been processed via ipsec) Allow protocol GRE in if it has ipsec-policy=in, ipsec Allow protocol GRE out if it has ipsec-policy=out,ipsec (Probably redundant) ** Ideally ** Drop protocol GRE out if doesn't have ipsec-policy=out,ipsec Regards Roger From: Christopher Hawker <chris@thesysadmin.dev> To: "public@talk.mikrotik.com.au" <public@talk.mikrotik.com.au> Date sent: Sun, 5 Sep 2021 23:01:08 +0000 Subject: [MT-AU Public] EoIP Tunnel that doesn't want to tunnel Send reply to: MikroTik Australia Public List <public@talk.mikrotik.com.au> [ Double-click this line for list subscription options ] Hi Everyone, I for some reason, have two MT devices (A-side is a CCR1009-8G-1S-1S+ and the Z-side is a CHR) and they don't seem to want to tunnel together. The tunnel comes up, two ICMP packets get through, and the link goes down. There is no firewalling in place (or has been disabled altogether for testing purposes) however the issue still manifests. The only thing is on the A side the public IP address is received by DHCP, however a reservation has been set by the carrier so the address will not change. *** A Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=192.0.2.10 mac-address=12:34:56:78:90:12 name=tun1 remote-address=203.0.113.10 tunnel-id=1 /ip address add address=172.21.254.2/30 interface=tun1 network=172.21.254.0 *** Z Side *** /interface eoip add allow-fast-path=no disabled=yes ipsec-secret="fakepass" local-address=203.0.113.10 mac-address=21:09:87:65:43:21 name=tun1 remote-address=192.0.2.10 tunnel-id=1 /ip address add address=203.0.113.10/29 interface=ether1 network=27.32.52.8 add address=172.21.254.1/30 interface=tun1 network=172.21.254.0 If anyone would be able to point out any issues or have any ideas, it'd be much appreciated! Thanks, Christopher Hawker _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au---------------------------- Roger Plant
participants (4)
-
Andrew Oakeley -
Christopher Hawker -
Philip Loenneker -
Roger Plant