IPSEC problems - Mac OS VPN server behind an RB2011
Hi all, I think I'm missing something obvious here, but it has been so long since I've done anything with IPSEC that I can't remember all of the tricks. The configuration is a RB2011, with two interfaces active - 1 goes to an Optus fibre WAN link, the other goes to a single subnet LAN via NAT. Inside that LAN, there is a Mac OS X box running an IPSEC VPN server for road warrior type access. This was previously working with a Cisco 881, but that has been replaced with the RB2011 to get a bit more flexibility. So far, I have not been able to establish a VPN link from the outside using the Mikrotik. As an aside, the test workstation has a public IP address with no NAT or firewalling involved, so there shouldn't be any problems on that end. I have forwarded ports 500, 1701, 4500 (all UDP) to the server, and (with some additional logging firewall rules), I can see the traffic hitting the router and being forwarded to the Mac server, but I can't see anything going back the other way. /ip firewall filter add chain=input comment="Allow ICMP" protocol=icmp add chain=input comment="Allow established connections" connection-state=established add chain=input comment="Allow related connections" connection-state=related add chain=input comment="Allow access to the administration" in-interface=wan-optus src-address=<my remote admin workstation> add action=drop chain=input comment="Drop anything addressed to the router coming in from WAN not specifically allowed above" in-interface=wan-optus add chain=forward comment="Forward on any established connections without rechecking rules" connection-state=established add chain=forward comment="Forward on any related connections without rechecking rules" connection-state=related add chain=forward comment="Allow some UDP ports in from Optus" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp *** various other allow rules redacted - all of these only touch TCP packets add action=drop chain=forward comment="Drop any invalid" connection-state=invalid add action=drop chain=forward comment="Drop any inbound traffic that is not specifically allowed by other rules" in-interface=wan-optus /ip firewall nat add action=masquerade chain=srcnat comment="NAT masquerade for Optus" out-interface=wan-optus add action=dst-nat chain=dstnat comment="NAT from Optus to Mac server - UDP ports" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp to-addresses=<internal IP of Mac server> *** various other dstnat rules redacted - all involve TCP Any tips would be much appreciated. Cheers, Thomas
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Thomas Jackson Sent: Friday, 30 May 2014 10:41 AM To: 'MikroTik Australia Public List' Subject: [MT-AU Public] IPSEC problems - Mac OS VPN server behind an RB2011
Hi all,
I think I'm missing something obvious here, but it has been so long since I've done anything with IPSEC that I can't remember all of the tricks.
The configuration is a RB2011, with two interfaces active - 1 goes to an Optus fibre WAN link, the other goes to a single subnet LAN via NAT. Inside that LAN, there is a Mac OS X box running an IPSEC VPN server for road warrior type access. This was previously working with a Cisco 881, but that has been replaced with the RB2011 to get a bit more flexibility.
So far, I have not been able to establish a VPN link from the outside using the Mikrotik. As an aside, the test workstation has a public IP address with no NAT or firewalling involved, so there shouldn't be any problems on that end.
I have forwarded ports 500, 1701, 4500 (all UDP) to the server, and (with some additional logging firewall rules), I can see the traffic hitting the router and being forwarded to the Mac server, but I can't see anything going back the other way.
/ip firewall filter add chain=input comment="Allow ICMP" protocol=icmp add chain=input comment="Allow established connections" connection-state=established add chain=input comment="Allow related connections" connection- state=related add chain=input comment="Allow access to the administration" in-interface=wan-optus src-address=<my remote admin workstation> add action=drop chain=input comment="Drop anything addressed to the router coming in from WAN not specifically allowed above" in-interface=wan-optus add chain=forward comment="Forward on any established connections without rechecking rules" connection-state=established add chain=forward comment="Forward on any related connections without rechecking rules" connection-state=related add chain=forward comment="Allow some UDP ports in from Optus" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp *** various other allow rules redacted - all of these only touch TCP
Hi Thomas, Have you considered terminating the IPSEC tunnels to the 2011 router? The thing about IPSEC is that both endpoints really need a public routable (and static) address configured - passing through NAT is possible using 1:1 translations, but can be quite a PITA in the best of times ;-) Cheers, Mike. packets add
action=drop chain=forward comment="Drop any invalid" connection-state=invalid add action=drop chain=forward comment="Drop any inbound traffic that is not specifically allowed by other rules" in-interface=wan-optus
/ip firewall nat add action=masquerade chain=srcnat comment="NAT masquerade for Optus" out-interface=wan-optus add action=dst-nat chain=dstnat comment="NAT from Optus to Mac server - UDP ports" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp to- addresses=<internal IP of Mac server> *** various other dstnat rules redacted - all involve TCP
Any tips would be much appreciated.
Cheers,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hey Thomas, It looks like you're missing protocols 50 and 51 (IPSEC ESP and IPSEC AH) which will need to be forwarded - Andrew On 30 May 2014 10:40, Thomas Jackson <thomas@thomax.com.au> wrote:
Hi all,
I think I'm missing something obvious here, but it has been so long since I've done anything with IPSEC that I can't remember all of the tricks.
The configuration is a RB2011, with two interfaces active - 1 goes to an Optus fibre WAN link, the other goes to a single subnet LAN via NAT. Inside that LAN, there is a Mac OS X box running an IPSEC VPN server for road warrior type access. This was previously working with a Cisco 881, but that has been replaced with the RB2011 to get a bit more flexibility.
So far, I have not been able to establish a VPN link from the outside using the Mikrotik. As an aside, the test workstation has a public IP address with no NAT or firewalling involved, so there shouldn't be any problems on that end.
I have forwarded ports 500, 1701, 4500 (all UDP) to the server, and (with some additional logging firewall rules), I can see the traffic hitting the router and being forwarded to the Mac server, but I can't see anything going back the other way.
/ip firewall filter add chain=input comment="Allow ICMP" protocol=icmp add chain=input comment="Allow established connections" connection-state=established add chain=input comment="Allow related connections" connection-state=related add chain=input comment="Allow access to the administration" in-interface=wan-optus src-address=<my remote admin workstation> add action=drop chain=input comment="Drop anything addressed to the router coming in from WAN not specifically allowed above" in-interface=wan-optus add chain=forward comment="Forward on any established connections without rechecking rules" connection-state=established add chain=forward comment="Forward on any related connections without rechecking rules" connection-state=related add chain=forward comment="Allow some UDP ports in from Optus" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp *** various other allow rules redacted - all of these only touch TCP packets add action=drop chain=forward comment="Drop any invalid" connection-state=invalid add action=drop chain=forward comment="Drop any inbound traffic that is not specifically allowed by other rules" in-interface=wan-optus
/ip firewall nat add action=masquerade chain=srcnat comment="NAT masquerade for Optus" out-interface=wan-optus add action=dst-nat chain=dstnat comment="NAT from Optus to Mac server - UDP ports" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp to-addresses=<internal IP of Mac server> *** various other dstnat rules redacted - all involve TCP
Any tips would be much appreciated.
Cheers,
Thomas
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
On Fri, 2014-05-30 at 11:27 +1000, Andrew Cox wrote:
It looks like you're missing protocols 50 and 51 (IPSEC ESP and IPSEC AH) which will need to be forwarded
Just to clarify, those are IP protocol numbers, not TCP/UDP port numbers... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 GPG fingerprint: 231A B066 CF91 1216 4F0F F2AC CE25 B8AA 46DC CC4F Old fingerprint: 1DB8 0599 13F0 E774 3811 6CA6 D6D0 AFA9 D91A 004C
Hi all,
I think I'm missing something obvious here, but it has been so long since I've done anything with IPSEC that I can't remember all of the
Hi Andrew, Oops, in my redaction of the unrelated entries (the other entries are forwards for various TCP services), I forgot to include these in the original email: /ip firewall filter add chain=forward comment="Allow IPSEC protocols (50)" protocol=ipsec-esp add chain=forward comment="Allow IPSEC protocols (51)" protocol=ipsec-ah /ip firewall nat add action=dst-nat chain=dstnat comment="NAT the IPSEC protocols" in-interface=wan-optus protocol=ipsec-esp to-addresses=<internal IP of server> add action=dst-nat chain=dstnat comment="NAT the IPSEC protocols" in-interface=wan-optus protocol=ipsec-ah to-addresses=<internal IP of server> Now, I have to apologise for the list noise. I've just tested again (completely out of frustration) and everything is working now, without me changing anything. When I was working on this yesterday morning, I had forgotten to add in the rules for protocol 50 and 51, but when I added them in last night, they didn't seem to have any affect. I'll have to do a bit more digging to figure out exactly why it is working now (first guess is that a table somewhere might have needed to flush). Thanks for the help Mike, Andrew and Karl Regards, Thomas -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox Sent: Friday, 30 May 2014 11:28 AM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] IPSEC problems - Mac OS VPN server behind an RB2011 Hey Thomas, It looks like you're missing protocols 50 and 51 (IPSEC ESP and IPSEC AH) which will need to be forwarded - Andrew On 30 May 2014 10:40, Thomas Jackson <thomas@thomax.com.au> wrote: tricks.
The configuration is a RB2011, with two interfaces active - 1 goes to an Optus fibre WAN link, the other goes to a single subnet LAN via NAT. Inside that LAN, there is a Mac OS X box running an IPSEC VPN server for road warrior type access. This was previously working with a Cisco 881, but that has been replaced with the RB2011 to get a bit more
flexibility.
So far, I have not been able to establish a VPN link from the outside using the Mikrotik. As an aside, the test workstation has a public IP address with no NAT or firewalling involved, so there shouldn't be any problems on that end.
I have forwarded ports 500, 1701, 4500 (all UDP) to the server, and (with some additional logging firewall rules), I can see the traffic hitting the router and being forwarded to the Mac server, but I can't see anything going back the other way.
/ip firewall filter add chain=input comment="Allow ICMP" protocol=icmp add chain=input comment="Allow established connections" connection-state=established add chain=input comment="Allow related connections" connection-state=related add chain=input comment="Allow access to the administration" in-interface=wan-optus src-address=<my remote admin workstation> add action=drop chain=input comment="Drop anything addressed to the router coming in from WAN not specifically allowed above" in-interface=wan-optus add chain=forward comment="Forward on any established connections without rechecking rules" connection-state=established add chain=forward comment="Forward on any related connections without rechecking rules" connection-state=related add chain=forward comment="Allow some UDP ports in from Optus" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp *** various other allow rules redacted - all of these only touch TCP packets add action=drop chain=forward comment="Drop any invalid" connection-state=invalid add action=drop chain=forward comment="Drop any inbound traffic that is not specifically allowed by other rules" in-interface=wan-optus
/ip firewall nat add action=masquerade chain=srcnat comment="NAT masquerade for Optus" out-interface=wan-optus add action=dst-nat chain=dstnat comment="NAT from Optus to Mac server - UDP ports" dst-port=500,1701,4500 in-interface=wan-optus protocol=udp to-addresses=<internal IP of Mac server> *** various other dstnat rules redacted - all involve TCP
Any tips would be much appreciated.
Cheers,
Thomas
_______________________________________________ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au
-----Original Message----- Now, I have to apologise for the list noise. I've just tested again (completely out of frustration) and everything is working now, without me changing anything. When I was working on this yesterday morning, I had forgotten to add in
I love it when I am not the ONLY one this happens to! :-D That's what this list is for :) Cheers! the
rules for protocol 50 and 51, but when I added them in last night, they didn't seem to have any affect. I'll have to do a bit more digging to figure out exactly why it is working now (first guess is that a table somewhere might have needed to flush).
participants (4)
-
Andrew Cox -
Karl Auer -
Mike Everest -
Thomas Jackson