Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have setup a point to point transport ipsec session between a ScreenOS router (SSG-5) and a Cisco 3925. The ipsec transport itself works great, but as soon as I try to direct the protocol 41 traffic over the transport, the packets don't transit properly.

I assumed at first that you would need to create a tunnel for the ipsec connection, then target the ip6in4 tunnel with outgoing-interface of the ipsec tunnel, but screenos won't let you create a tunnel on a tunnel.

Additionally, I tried using a policy-based vpn but when I attempt to use "tunnel vpn" as a policy target it tells me unknown command? Is there a master on/off switch for policy based ipsec?

Below is what I think is the pertinent configuration, though I'll be more than happy to provide more info as required.

set zone id 105 "mytunnel_TUNNEL"
set zone "mytunnel_TUNNEL" tcp-rst
set interface "tunnel.5" zone "mytunnel_TUNNEL"
set address "mytunnel_TUNNEL" "fdee:7e1e::/32" fdee:7e1e::/32
set ike gateway "micmplsv4" address Main outgoing-interface "ethernet0/0" preshare "igdZeIcKNobfusol+CQcpIfvwnFwrxb5g==" sec-level compatible
set vpn "mytunnel" gateway "micmplsv4" no-replay transport idletime 0 sec-level compatible
set vpn "mytunnel" monitor optimized rekey
set vpn "mytunnel" id 0x16 bind interface tunnel.3
set vpn "mytunnel" proxy-id check
set vpn "mytunnel" proxy-id local-ip remote-ip "ANY"
set policy id 137 from "DMZ" to "mytunnel_TUNNEL"  "fdbe:a922:a316:2::/64" "fdee:7e1e::/32" "ANY" permit
set policy id 136 from "mytunnel_TUNNEL" to "DMZ"  "fdee:7e1e::/32" "fdbe:a922:a316:2::/64" "ANY" permit
set interface "tunnel.3" zone "Untrust"
set interface tunnel.3 ip unnumbered interface ethernet0/0
set vpn "mytunnel" id 0x16 bind interface tunnel.3
set route interface tunnel.3

ip access-list extended mic2pg
 permit ip host host
crypto ipsec transform-set transport-esp-3des-sha esp-3des esp-sha-hmac
 mode transport
crypto map vpnmap 30 ipsec-isakmp
 set peer
 set transform-set transport-esp-3des-sha
 match address mic2pg
interface GigabitEthernet0/0.1
 encapsulation dot1Q 1 native
 ip address
 crypto map vpnmap
interface Tunnel3
 no ip address
 ipv6 address FDEE:7E1E:100:F002::1/64
 ipv6 enable
 tunnel source
 tunnel mode ipv6ip
 tunnel destination
share|improve this question
bahamat's answer gets an upvote because it is absolutely the cleanest way to do this between two ScreenOS units, however I have yet to find a way to make it work outside of a pure ScreenOS environment. – Peter Grace Aug 21 '11 at 15:22

I've done tons of IPv6 on ScreenOS. Both natively and tunnels. I've done exactly what you're asking about (although, not with a Cisco at the other end). Here's what to do.

Get rid of the 6in4 stuff. Use only one tunnel interface, and unset the proxy-id on both sides. Build the tunnel with v4 endpoints then route the remote v6 prefix as well as the remote v4 prefix to the tunnel interface.

Update: As requested, example config.


  • Local v6 supernet is fd28:e1f3:d650:1000::/56
  • Remote v6 supernet is fd28:e1f3:d650:2000::/56
  • Significant v4 portions have been left out because I think you get it.


set interface ethernet0/0 zone Untrust
set interface ethernet0/0 ip
set interface ethernet0/0 route

set interface ethernet0/2 zone Trust
set interface ethernet0/2 ip
set interface ethernet0/2 route
set interface ethernet0/2 ipv6 mode router
set interface ethernet0/2 ipv6 enable
set interface ethernet0/2 ipv6 ip fd28:e1f3:d650:1010::/64

set interface ethernet0/2 ipv6 nd nud
set interface ethernet0/2 ipv6 ra link-address
set interface ethernet0/2 ipv6 ra link-mtu
set interface ethernet0/2 ipv6 ra managed
set interface ethernet0/2 ipv6 ra other
set interface ethernet0/2 ipv6 ra preference high
set interface ethernet0/2 ipv6 ra prefix fd28:e1f3:d650:1010::/64
set interface ethernet0/2 ipv6 ra reachable-time
set interface ethernet0/2 ipv6 ra retransmit-time
set interface ethernet0/2 ipv6 ra transmit

set zone name v6remote
set interface tunnel.20 ip unnumbered interface ethernet0/0
set interface tunnel.20 zone v6remote
set interface tunnel.20 ipv6 mode host
set interface tunnel.20 ipv6 enable
set interface tunnel.20 ipv6 nd dad-count 0
set interface tunnel.20 ipv6 nd nud

set ike p1-proposal AES256-SHA preshare group2 esp aes256 sha-1 second 28800
set ike p2-proposal AES256-SHA group2 esp aes256 sha-1 second 3600

set ike gateway gateway2v6remote address Main outgoing-interface ethernet0/0 preshare "secret-word" proposal AES256-SHA
set vpn tunnel2v6remote gateway gateway2v6remote replay tunnel idletime 0 proposal AES256-SHA 
set vpn tunnel2v6remote bind interface tunnel.20

set policy from v6remote to trust v6remote v6local ANY permit log count 
set policy from trust to v6remote v6local v6remote ANY permit log count

set route fd28:e1f3:d650:2000::/56 interface tunnel.20 gateway ::
share|improve this answer
I'm not doubting you at all, just curious about how your description would be implemented. If I'm routing the v6 prefixes over the tunnel, does that mean I should be setting the tunnel in ipv6 host mode and giving it an ip address? Could you sanitize one of your existing, working configs and post it up so I can see how you've done it? Meanwhile, I'm going to try this approach in as many variations as I can. – Peter Grace Aug 21 '11 at 13:21
I'll update my answer with an example config. – bahamat Aug 21 '11 at 14:51
Thanks bahamat! I tried this out first on two screenos units, and behold, it did work. I was trying to figure out HOW it worked so that I could try to translate this to linux ipsec and cisco ipsec, but sadly it does its secret magic by setting the proxy-id's to in both directions, which seems not to bother ScreenOS, but will definitely annoy both linux and cisco, as they make routing decisions based on the SA table. Also unfortunately, I know linux doesn't want to do ipv6 tunnel endpoints inside ipv4 encap. – Peter Grace Aug 21 '11 at 15:20
Yeah, I like I said, I've never used it with cisco's. – bahamat Aug 21 '11 at 16:19

I know that there is a problem in ScreenOS with routing of 6in4 traffic directly. What people usually do is to create loopback interface for terminating end of 6in4 tunnel and then route IPv6 traffic through it. I use similar configuration for my 6in4 tunnel with sixxs, but I think general principle may be applicable to your case as well. Please check this link for more info especially "Update sept 13, 2009" part.

share|improve this answer
I tried this approach last night and sadly, though you can set the ip on the loopback adapter, there still seems to be no way to get the vpn traffic to go over the ip6in4 tunnel. I'm thinking this project is never going to work right on ScreenOS unless they fix this behavior in a later release. – Peter Grace Aug 18 '11 at 17:39
6in4 works perfectly on ScreenOS. I do it all the time. – bahamat Aug 20 '11 at 4:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.