Device-originated traffic source

[LAN10PAN]

Hi,

I am currently learning about PAN devices, and have a PA-500 in a lab environment (PANOS 3.1.6). Client internet access through the PA-500 does not pose a problem. However traffic originating from the PA-500 seems to be sourced from the management interface regardless of the service route configuration. e.g. I cannot resolve host names via DNS if the management port does not have access to the DNS server. If the DNS server resides in the internet, I need internet access on both the management and outside ports. This seems a bit complicated. Is there anyway I can source traffic from other interfaces? As said before, adding networks and source interfaces under service route configuration does not work. Am I missing something?

Regards,

Ingo

[James]

Hi Ingo,

The Service route configuration is the correct place to do this.

However - the primary and secondary DNS servers in the device configuration are for backup purposes, not failed lookups.  So that means, if you can connect to the primary server and get a response - then it is up.  There will be no further lookups to the secondary DNS server, unless the primary is down.

This means, you will need the Internal server to be abe to do external lookups as well.

Best Regards

James

[LAN10PAN]

Hi James,

Thank you for the response. Let my try to clarify:

Goal: since alot of our customers do not have OOB Management, we usually use the inside/trust interface for management purposes (with permitted IPs of management stations) and disconnect the management port. So my intention is not to use the PA-500 management port at all.

Since device originated traffic uses the management port as the source by default, I entered service routes. e.g. 0.0.0.0/0 with the outside interface public IP as source address. Also I entered a route to the internal LAN, e.g. 172.16.1.0/24 with the inside interface IP as source address.

So in theory (correct me if I'm wrong), if the PA-500 sends DNS/ICMP/NTP queries to a public server, the traffic should be sourced from the outside interface. If the PA-500 sends DNS/ICMP/NTP queries to a Server in the LAN, the inside interface should be used as the source. The same goes for dynamic updates.

In practice however the PA-500 still uses the management port as the source. I notice this when I sent a ping from the PA-500. If I ping without specifying the source interface I get the following output:

admin@PA-500-IV> ping host 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Host Unreachable

If I ping sourced from the outside interface I get:

admin@PA-500-IV> ping source 92.x.x.x host 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 92.x.x.x : 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=1 ttl=248 time=27.7 ms

The same goes for DNS queries and other traffic to e.g. the public DNS server 4.2.2.2

Once I configure the management port with an IP and gateway which has internet access (through a second Firewall) everything works fine. The PA-500 however still uses the management interface as a source regardless of the service route configuration. I can see this in the logs of the other firewall.

Is there an explanation for this behavior??

Regards
Ingo

[kbrazil · Accepted solution]

In addition to the Service Route "destinations" configuration (where it seems you have put 0.0.0.0/0) there are "services" that are pre-defined.  DNS is one of them.  I believe the defined service may take precedence over the "destinations" configuration since "destinations" is supposed to be used for any other traffic not specified in the services section.

Also, I was not aware that the "destinations" area allows subnets.  I think it should be a single IP or FQDN, so the 0.0.0.0/0 configuration may not work.

Ping will always source from the management interface by default unless you modify the source option on the command.

Cheers,

Kelly

[LAN10PAN]

Hi Kelly,

thank you for the feeback! Since entries with subnet mask notation were accepted under service route configuration (also after commiting), I assumed it was a valid configuration. I tried entering single IPs and it did the trick. The (host) routes also seem to take precedence over the services as described in the configuration guide. Now I can use the services without having to have internet access via the management port.

Ingo