Hi all,

I want IPv6 experience.
Our main link at work is Internode, so I can get native IPv6.
I want an isolated test net that can talk IPv6 to the internet,
without leaking IPv6 into my production network.

I think I can do this by simply enabling IPv6 in the bastion's
kernel, and dropping IPv6 packets that aren't going between the test
net and the internet.

Is this safe?  Can IPv6 leak into my production net?





More details follow
-------------------

I have a /24 IPv4 network with Internode. My router (known as Alpha)
is a full Ubuntu Lucid server with 4 downstream interfaces (each
serving a public /26) and 2 upstream ppp connections. (ppp0 is
Internode, ppp1 is an irrelevent backup Exetel link.)

| cyber@alpha:~$ ip link
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
|     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
| 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
|     link/ether 1c:6f:65:c6:47:46 brd ff:ff:ff:ff:ff:ff
| 3: managed: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|     link/ether 00:1b:21:b6:65:99 brd ff:ff:ff:ff:ff:ff
| 4: unmanaged: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|     link/ether 00:1b:21:b6:65:98 brd ff:ff:ff:ff:ff:ff
| 5: dmz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|     link/ether 00:1b:21:b6:65:9b brd ff:ff:ff:ff:ff:ff
| 6: scratch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|     link/ether 00:1b:21:b6:65:9a brd ff:ff:ff:ff:ff:ff
| 518: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
|     link/ppp
| 542: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
|     link/ppp

IPv6 is disabled in Alpha's kernel. I want to give Alpha an extra
network interface called "ip6test" (or rename eth0 above) and have IPv6
passed through (and completely *isolated*) to the network segment
connected to that NIC. The top priority is ensuring that Alpha and the 4
IPv4 subnets (managed, unmanaged, dmz, and scratch) all drop IPv6
packets until I've more IPv6 experience.

Here's what I *think* is required, but I'm looking for a second opinion:

| #!/usr/sbin/ip6tables-apply
| *filter
| :OUTPUT         ACCEPT          # Local users/processes are trusted.
| :INPUT          DROP            # Ingress policy is "default deny".
| :FORWARD        DROP            # Routing policy is "default deny".
| :PRELUDE        -               # Best practices for filtered chains.
|
| ## Quickly handle the essentials of a "default deny" environment.
| ## Anything left after this chain implicitly has --ctstate NEW.
| -A INPUT -j PRELUDE
| -A FORWARD -j PRELUDE
| -A PRELUDE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
| -A PRELUDE -m conntrack ! --ctstate NEW -j DROP -m comment --comment "Same as --ctstate INVALID."
| -A PRELUDE -o ip6test -p icmp -j ACCEPT -m comment --comment "For now, only allow ICMP to test network"
| -A PRELUDE -i lo -j ACCEPT
|
| ## YOUR RULES GO HERE
| -A FORWARD -o ip6test -p tcp --dport ssh -j ACCEPT -m comment --comment "Allow IPv6 SSH traffic to test network"
|
| ## Finally, politely reject all other attempts.  Omit these to use the
| ## chains' default policies (DROP, above) instead.
| -A INPUT   -j REJECT
| -A FORWARD -j REJECT
| COMMIT

So I expect, having enabled IPv6 in Alpha's kernel, Alpha
gets an IPv6 address on ppp0, but due to the above firewall,
IPv6 traffic not from/to ip6test will be rejected. Due to the
PRELUDE chain, ICMPv6 will be allowed to machines connected to the
ip6test interface, all of which I expect toobtain an IPv6 address.  The
FORWARD chain will allow direct SSH to those machines.

Assuming all the above is suitably secure, I then expect to carefully
open more IPv6 access up to the ip6test interface for further testing.

Further, will I need radvd or similar on Alpha, or will it be good
enough to handle that on another box connected to the ip6test interface,
or let Internode deal with it?

How does this all sound?

--
Regards,
Matthew Cengia

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJRt/imAAoJEHp+N/M7InLoCsYP/3N2ggaKr3lp4Qi1O5NRz/fQ
HAu5WniE6q/DOrDK8QUvXxtGlISyT0SutVkSewNrGuyMWutLspoI4c0dTUrm7q9J
7I5tjfOt/3p2lAhrF1PgdV/zmrtdeoyNYCcFOH202cSeitFUqjRc5MSSD1F5RC5o
v+bG3ZTBj7gNZy+05oSAMAX2OQsrU6tZRHOJy7jaYWTLcdRjI9jwNIwr7gg/coFf
xXO2ZBgcvSGmwkl707oVnJkbMkrM/PgV0UVPCnCcyN4tXLRu7M98OkiNAFnKvu0Q
C7kLF65aOC4zBfnCFMUjdN+Cg6Pa3yWuvdkxdE5hW/LbEVGze5jwMEoVsvR8mxxk
fC5hIcIkKLUyx6VVv5iSAyqWMnV5jZSzLVjycsSE2GOC2qpucszb5V7oVrEdrUwc
G1XZXlcbn+HVLTBidBsQ7NU3KGi7PQXvAgeBiXLVOYYijE9btFlVJflepdBKfxig
d6zA46Cf+MIlOb4LPmMhcK37SibPzxTItUqCEvHCevbUKXeHdNLFxOHh+mNNFAJ2
AWAOFKbdPiBsgCah+XRYIMYi/fNEsiz9RWMsRNJGjahmKqBgHer3hdrMWavpNkgM
TBV5OCzkvMyr0K4rG4jGmIAudQQoqR18EQdxANUpQxVZ46fWycKqhxUs9BKQsBSb
pTMYKe0Lm1NsQd/wnh6n
=/F6W
-----END PGP SIGNATURE-----

_______________________________________________
luv-main mailing list
luv-main@luv.asn.au
http://lists.luv.asn.au/listinfo/luv-main