Don't Port that thing at me!

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Don't Port that thing at me!

L1 Bithead

Hi All,

 

Heres my problem, I am setting up a L2TP/IPsec remote access VPN for staff and I am having issues with the IKE traffice on port 500. We are using an internal RRAS server which I have set the palo up to NAT all port 500 traffic and IKE services to once it hits our outside interface. We also currently have 2 Site-to-Site VPNs setup and running on the same outside interface, this is causing conflict. How can I direct/filter the remote access VPN traffic to the RRAS with out effecting the site-to-site traffic? I am out of ideas.

 

Any help will be much appreciated.

 

Thanks

1 accepted solution

Accepted Solutions

Not sure what stops from having 2 NAT rules?

Use following example.

1.1.1.1 is your firewall wan IP

5.5.5.5 is IPSec peer IP

10.10.10.10 is PPTP IP in your internal network.

 

 

NoNAT.PNG

 

First rule avoids applying NAT for traffic from IPSec peer so traffic hits firewall wan IP.

Second rule will NAT everything else further.

You probably want to add udp-500 port into Service field to be more specific.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

View solution in original post

8 REPLIES 8

Cyber Elite
Cyber Elite

This traffic to RRAS is coming from roaming users with changing IPs?

If so then create 2 NAT rules.

 

Top one:

From untrust to untrust.

Specify source address (your IPSec peer IPs) and destination IP (interface IPSec runs on your side).

Leave Source NAT and Destination NAT unconfigured.

 

Second rule is for regular DNAT rule to nat port 500 to RRAS.

 

First rule will avoid applying NAT for site-to-site IPSec.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

So How can I define Peers Source IP's if they are roaming?

You specify source IP on first rule. 

In this rule you specify those 2 peer IPs.

You said: "We also currently have 2 Site-to-Site VPNs setup and running on the same outside interface"

 

In second rule that matches roaming users you leave source IP to Any.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Ah right, let me give this a try and let you know how it goes.

If that doesn't work for you, ask the MS admin to change to PPTP on the RRAS server and this will use port 1723 and GRE 47 instead.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

Raido - Still a no go. it wont allow both to run side by side, only one of the other.

 

pulukas - We currently have a PPTP VPN setup, we are tying to move away from that protocal to something more secure.

Not sure what stops from having 2 NAT rules?

Use following example.

1.1.1.1 is your firewall wan IP

5.5.5.5 is IPSec peer IP

10.10.10.10 is PPTP IP in your internal network.

 

 

NoNAT.PNG

 

First rule avoids applying NAT for traffic from IPSec peer so traffic hits firewall wan IP.

Second rule will NAT everything else further.

You probably want to add udp-500 port into Service field to be more specific.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

After a few days of testing, looks like everything is working well. I removed port 500 from the NAT translated port option and added UDP port 500 to services, no conflicts so far. Thanks for all your help, I really appreciate it.

  • 1 accepted solution
  • 5179 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!