IPV6 VirtualIP

2001:1890:1222:900::32

Is that above prefix fully routed? 2001:1890::/29 *[BGP/170] 5d 17:30:21, localpref 100 AS path: 7018 I, validation-state: unverified > to 2001:1890:111d:111d:12:255:255:31 via fe-0/0/1.0 Have you ran any diag flow and/or sniffer looking for traffic? Does your ipv6 route-table have a default route? Btw can' t ping it nor telnet to port 25, I would check all of the above and the fwpolicy6 rules

The 2001:1890:1222:900::32 is part of a 2001:1890:1222:900::/56 real IPV6 subnet from internet provider The fd03:cd22:4796:9a9d::32 is part of a fd03:cd22:4796:9a9d::/64 internal private IPV6 subnet and there is a static route in the routing table ::/0 IPV6_Gateway similar to the IPV4 static route of 0:0:0:0/0.0.0.0 IPV4 gateway I have tried diag and sniffer and I can see a request at wan1 with xxxx-> 2001:1890:1222:900::32 syn xxx when i try to telnet but it goes nowhere and i get xxx packets filter, 0 kernel packets I figure the problem is with the VIP6 Virtual ID where it is not correctly translating the ext IPV6 to the Internal IPV6 with NAT. Has anyone sucessfully set this up?

So you have to use a private address space ULA ? IPv6 was suppose to eliminated and reduce nat, suggestion how is that host configured ? I' m assuming it' s static and definetely not EUI64, so could try the link-local-address. If the diag sniffer shows external packets inbound than that' s good, you might want to dump on the backend and see what' s happening. The diag debug flow filter6 would be helpful here. And I' m assuming you can ping the host from the firewall?

I still want to run NAT because it separates the internal IP' s from the external IP' s and allows me to selectively implement external IP' s that map to a certain server. The internal network is static private addres space of /64 with a unique guid prefix that corresponds to the standard. I' ve come to the conclusion that the VIP6 function in FortiOS 5 is flawed and does not work. The examples given in the What' s new handbook have typos and the examples just don' t work. The Virtual IP for IPV4 is straight forward and works fine. I guess I will have to wait for a firmware update to receive traffic over IPV6 and route it to an internal IPV6 server as I have spent way to much time on what should be a 5 minute policy.

Here is proof that the VIP6 does not function correctly. Create VIP for IPV4 config firewall vip edit " Bryan Server IPV4" set extip 12.174.50.187 set extintf " wan1" set mappedip 10.10.0.50 next end now telnetting to 12.174.50.187 id=13 trace_id=202 msg=" allocate a new session-0003b3d0" id=13 trace_id=202 msg=" find SNAT: IP-10.10.0.50(from IPPOOL), port-0" id=13 trace_id=202 msg=" find SNAT: IP-12.174.50.186, port-21973" id=13 trace_id=202 msg=" VIP-10.10.0.50:25, outdev-unkown" id=13 trace_id=202 msg=" DNAT 12.174.50.187:25->10.10.0.50:25" id=13 trace_id=202 msg=" find a route: gw-10.10.0.50 via internal" id=13 trace_id=202 msg=" Allowed by Policy-2: SNAT" id=13 trace_id=202 msg=" SNAT 10.10.0.157->10.10.0.1:21973" Now performing the same for IPV6 config firewall vip6 edit " Bryan Server IPV6" set extip 2001:1890:1222:900::32 set mappedip fd03:cd22:4796:9a9d::32 next end id=13 trace_id=9 msg=" allocate a new session-00003962" id=13 trace_id=9 msg=" find NAT: IP-fd03:cd22:4796:9a9d::32, port-25" id=13 trace_id=9 msg=" DNAT 2001:1890:1222:900::32:25->fd03:cd22:4796:9a9d::32:25" id=13 trace_id=9 msg=" VIP-fd03:cd22:4796:9a9d::32:25, outdev-unknown" id=13 trace_id=9 msg=" Check policy between internal -> internal" id=13 trace_id=9 msg=" Denied by forward policy check" shows that while the device address is translated it is not forwarded on the internal network. These were created with identical policies one for IPV4 and one for IPV6. The VIP6 policy does not perform the routing of the packet to the destination.

Denied by forward policy check

You have posted your VIP configuration but what about the fwpolicy6 ? A " Denied by forward policy check" is like 9 out of 10 times related to no policy. It' s been that way with ipv4 and I would assume ipv6 is the same. I would review all of the fwpolicies and ordering of such. See the below reference tips from KB. " http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD31702" FWIW ; if it was matching a fwpolicy6 id , it would have presented the policy #.

Here is the IPV6 policy edit 6 set srcintf " wan1" set dstintf " internal" set srcaddr " All IPV6" set dstaddr " Bryan Server IPV6" set action accept set schedule " always" set service " SMTP" next Here is the IPV4 policy edit 2 set srcintf " wan1" set dstintf " internal" set srcaddr " All IPV4" set dstaddr " Bryan Server IPV4" set action accept set schedule " always" set service " HTTP" " HTTPS" " FTP" " DNS" " SSH" " IMAP & IMAP TLS" " IMAP SSL" " POP3 & POP3 TLS" " POP3 SSL" " SMTP" " SMTP SSL" " SMTP TLS" " XMPP" next which are pretty straight forward. The IPV6 policy which is doing the address change as requested is not forwarding it on the internal network even though it is set to accept thus the problem. Configured identically and both IPV6 and IPV4 work internal to external for browsing. This seems like a Fortinet OS problem.