configuring NAT with TAGGED subinterfaces

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

configuring NAT with TAGGED subinterfaces

Not applicable

In order to overcome the limited number of physical interfaces on the PA-200, I need to have one physical interface handle traffic for two different zones, A & B. These zones need to talk to each other and to other internal zones (with security policies enforced by the firewall). In addition, they need to access the Internet using Dynamic-IP-and-port NAT, using the IP address of the external interface (which is on the Internet zone).

All the ethernet interfaces are configured as layer 3 and all are on the same virtual router. They work fine with NAT. I'm having trouble with Zone B.

For zone A, I used ethernet1/3. It has its own static RFC1918 subnet. Untagged Subinterface is not checked.

For zone B, I use ethernet1/3.1. It has another static RFC1918 subnet. Its Tag is 3.

Now I attach a workstation to physical interface 3 and I create a virtual interface on the workstation with Tag 3. I configure this virtual interface with an appropriate IP address, subnet, and gateway for zone B. I turn off the "normal" Ethernet interface on the workstation. (This is all done through Mac OS 10.8 System Preferences > Network.)

At this point I can ping devices on the Internet side of the firewall. I can also traceroute.

However, web pages don't load and DNS doesn't seem to work.

Any suggestions on what I might be doing wrong or how to make this work?

1 accepted solution

Accepted Solutions

Thank you for your help, but it turns out this was a simple workstation configuration oversight on my part.

When I configured the virtual interface on my Mac, I didn't notice that the DNS server had to be set per-interface, and that it wasn't set. This may be unique to virtual interfaces and/or Mac OS X 10.8.

Once I added a DNS server to the interface, everything worked fine.

View solution in original post

5 REPLIES 5

L6 Presenter

Hi Elliot,

The fact that the ping traffic from the workstation is working and the rest of the traffic failing makes me believe that there is some thing wrong with the security policies. If your ping traffic is going through, means you have the proper routes, nat and l3 configuration. Can you double check your security polices?. Also please do look at the traffic logs and see if you can see find the reason for the packet loss (assuming you are logging everything via security policies). If the issue is with security policies then you will not see any active sessions on the firewall, you can check this from the cli with "show session all fitler source "workstation ip". However if you are able to see some dns/ web browsing active sessions for the workstation ip then there might be another issue. 

Thanks,

Sandeep T

Well, I am not able to look at the firewall at this moment--will be in a position to do so in a few hours. But I'm quite sure the security policy is the same for Zone A and Zone B--that is I included them both in the same virtual router and the same policy, which specified allowing traffic from any of the internal zones.

When I get a chance I'll increase the log level and retest.

However, it occurred to me that the reason web pages aren't loading is (probably) because DNS isn't working. I believe my ping/traceroute tests were to IP addresses while web was to a domain name. I will also test accessing a web page by IP address.

If it comes down to just DNS not working, then note that DNS uses UDP both outbound and inbound. On Mac, traceroute is (by default) UDP outbound and ICMP inbound. Ping is ICMP both outbound and inbound. If you put this all together then it may be that it's just the DNS UDP return packets which aren't being dellivered.

It could be DNS issue. But the reason for the DNS not working could be because of the security rules. When you get a chance look at the session info. If you are able to see the DNS active sessions on the firewall then security policies are good. Also check your a dns settings on the workstation.

Thank you for your help, but it turns out this was a simple workstation configuration oversight on my part.

When I configured the virtual interface on my Mac, I didn't notice that the DNS server had to be set per-interface, and that it wasn't set. This may be unique to virtual interfaces and/or Mac OS X 10.8.

Once I added a DNS server to the interface, everything worked fine.

L3 Networker

Hi Elliot,

I'm not sure if I will get an answer, but I wanted to write you anyway.  I see that you are using a L3 physical interface with a defined subnet on the physical interface and a subnet defined on a L3 sub-interface that is tagged with a vlan ID.

On my FW config I have eth1/1 for my WAN link (which is a L3 untagged network), eth1/3 through eth1/8 setup as physical L3 interfaces, untagged, untagged sub-interfaces (NOT CHECKED), and then about 6 vlans assigned to L3 sub-interfaces.  (I think this is setup much like you based on your above description.)  When I enabled the described setup, I failed to recognize that some devices on my network could not handle vlans.  I tried to enable a separate, available, physical port to a L3 untagged interface, but it seemed that things wen't haywire and systems were unavailable and not properly working. 

I'm a little gun shy to make any changes at the moment that could cause this problem as it would involve me driving 60+ miles and a couple hours of downtime that I can't afford to fix the problem.

This has been particularly challenging as we've consolidated our networking into two core switches which are trunked together. I've lost access to the management ports on the firewall as they do not support vlan tagging. I can provide a screen shot if that is helpful.  Thank you for any help you can provide.  There isn't much out there about this.

  • 1 accepted solution
  • 3975 Views
  • 5 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!