IPv6 firewall with IPv4 bridge?

[jgro]

I thought I knew what I was doing when I bought the hEX RB750Gr3 but apparently I’m out of my league. I only know as much networking stuff as I need to in order to set up high-availability web services and Open VPN, which is apparently not enough. Please help me come up with a plan of attack for my situation. Feel free to refer me to links to documentation, but what I have read on the wiki so far has not been all that helpful.

I’m trying to upgrade my small office network to support IPv6. WAN has dual stack and I want to run a dual stack LAN as well. All I want the hEX for is (a) firewall security for IPv6 (preventing inbound connections, except for specific host/port combos) and (b) inbound VPN access to LAN over IPv4. I plan to set up the network topology like this:
WAN router ↔ hEX ↔ WiFi router/NAT/DHCP ↔ Layer 2+ switch ↔ everything that is wiredCurrent setup has WiFi router doing NAT and DHCP for 2 private LANs: our shared wired LAN plus an isolated WiFi-only guest LAN that can only connect to the WAN. I’d like to not have to set that up all over again on the hEX, both because it’s a pain to set up (really beyond my current level of knowledge) and because that’s work the WiFi router can happily offload from the hEX. So I was thinking that I could start by just blindly forwarding all IPv4 packets from WAN to WIFi (say, ether1 to ether2). Is that a reasonable approach? How would I best implement that? I don’t need any processing on the hEX because we can rely on the WiFi router to protect the LAN, although basic DoS protection would be nice. What I’m probably most unsure about is if I can drop an IPv6 packet from the bridge input filter and still have that packet available to the firewall and router.

As for IPv6, the WiFi router provides no protection at all, so I need to set up stateful packet inspection to block any incoming traffic on IPv6 that is not part of an established outbound connection. Of course, being IPv6, NAT is not needed. These packets have to traverse the same WAN and LAN ports as the IPv4 packets, which is where I get really unsure if this is even practical at high throughput (300 Mbps).

Finally, I want to set up VPN access. I’d love it if I could set it up to allow Bonjour to traverse it so I could access the office printer easily, so I guess that means L2TP/IPsec since I’ll have an Apple device at the other end, but even then I’m not sure what to do to enable the “local” multicast traffic to cross the VPN. I can set up another post just to cover that, I only bring it up here to point out that this means probably using another port on the hEX to direct VPN traffic around the WiFi router and directly to the switch, right?

Does this sound like a winning plan? Do you have a better idea? Or should I just send back the hEX and live with IPv4-only for a while longer?

[jgro]

I gave up on this approach once I found that the WiFi can, without DHCP and NAT, still provide separation of the main and guest networks. It does it by putting the guest traffic on a separate VLAN. Once I figured that out, I just moved all the DHCP and NAT to the hEX and put the WiFi in Access Point (bridged) mode. So now everything is plugged into the switch except the WAN router. You can read details of my solution in this other forum post.

[idlemind]

@jgro

Finally, I want to set up VPN access. I’d love it if I could set it up to allow Bonjour to traverse it so I could access the office printer easily, so I guess that means L2TP/IPsec since I’ll have an Apple device at the other end, but even then I’m not sure what to do to enable the “local” multicast traffic to cross the VPN. I can set up another post just to cover that, I only bring it up here to point out that this means probably using another port on the hEX to direct VPN traffic around the WiFi router and directly to the switch, right?

For this item, local multicast or stuff in the 224.0.0.0/24 range like SSDP or Bonjour are not meant to escape routed boundaries. Even with a proper multicast environment setup you’ll see it isn’t forwarded. You’ll likely want to look into DNS based wide-area service discovery mechanisms. That said their are some commercial properties that do “bad” things to Bonjour to make it more span VLANs or hops. I think the better solution is to use the right tool for the job personally.

With that in mind, you should be able to create a VPN pool that, /shudder, shares your IP space with your LAN network and then you can enable proxy-ARP. I wouldn’t do this as proxy-ARP is a known security issue and can have the knock-on effect of allowing traffic to escape VLANs that otherwise wouldn’t.