PAN routing IPv6 traffic to UnTrust with default route pointing elsewhere

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

PAN routing IPv6 traffic to UnTrust with default route pointing elsewhere

L4 Transporter

I have a PAN on the internet with only IPv4.  I have an ASA dual stacked that I want to send IPv6 traffic from hosts connected behind the PAN to the ASA via the LAN.  All the interfaces on the PAN in the path have IPv6 configured. However, when the pan receives IPv6 packets that need to route it simply sends it out the UnTrust zone vs the Trust zone where my default and other static IPv6 routes reside.   Note IPv4 is working fine and I can ping the Lab interfaces from the host behind the PAN and so forth, its just any IPv6 traffic that needs to be routed past (or through) these PANs that gets punted to the UnTrust zone and I can't figure out why.    Its like its not even looking at the IPv6 route table.  

 

Next hop of IPv6 edge gateway ASA: 2403:8600:80CF:E100:2000::3

PAN Trust interface:  2403:8600:80CF:E100:2000::5/68

PAN Lab interface: 2403:8600:80cf:e101:2000::1/68 

PAN Lab next hop: 2403:8600:80cf:e101:2000::2/68 

PAN Lab CIDR: 2403:8600:80cf:e10c:3780::/73

PAN Lab host: 2403:8600:80CF:E10C:3710::10

Eth1/1 is my Trust interface and Eth1/15 is my Lab interface

 

IPv6 route table is below:

drewdown_1-1627585916395.png

I have policies allowing all the traffic but it seems like anything it doesn't have a specific IPv6 route for it sends it to the Untrust zone even though the default route is pointing out eth1/1 to 2403:8600:80CF:E100:2000::3.  Why would the PAN still try to send the traffic out the UnTrust interface at this point? 

 

In the logs below you can see a ping from the ASA (.3) gets punted to UnTrust.  But a ping from the PAN itself (.1) routes within that zone without issue all to the same host 2403:8600:80CF:E10C:3710::10.  No matter what I do I cannot get the PAN to route all IPv6 traffic to the trust or lab zones, none of it should be going to untrust as there is no IPv6 configured on that zone/interface.  

 

drewdown_0-1627587532904.png

 

 

 

1 accepted solution

Accepted Solutions

so if you have PBF for internet redundancy and your IPv6 gateway is via some other zone/interface outside of your untrust then you need 2 x PBF rules in both directions for that IPv6 traffic.  Simply having one or the other will break it in either direction.  

 

drewdown_4-1627660138166.png

 

 

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

@drewdown,

Have you tried looking at the route table directly on the CLI to ensure that it isn't installing the route incorrectly or learning it from your interface undesirably? 

@BPry 

 

I figured it out part of it....stupid PBF.  So I had PBF for IPv4 internet redundancy and if I added the source IPv6 network to it the traffic went in the right direction from Trust > Lab but not the other.  And since I don't have IPv6 on the egress interface I had to create a no PBF for the IPv6 traffic and set it to Not forward.  Once I did that it started working in both directions but not back from the internet.  

 

 

 

 

So now I have  similar issue with IPv6 traffics return path from the internet.   So the return or inbound IPv6 traffic comes across the Trust interface and should all be routed to the LAB but it is routing that traffic to UnTrust.   

 

This is the no IPv6 PBF:

drewdown_1-1627659474064.png

 

Internet > Trust > Lab but its going Internet > Trust > UnTrust so something not right with my PBF but not clear on what:

 

drewdown_2-1627659584727.png

 

so if you have PBF for internet redundancy and your IPv6 gateway is via some other zone/interface outside of your untrust then you need 2 x PBF rules in both directions for that IPv6 traffic.  Simply having one or the other will break it in either direction.  

 

drewdown_4-1627660138166.png

 

 

  • 1 accepted solution
  • 3725 Views
  • 4 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!