![]() |
|
FreeBSD Security Securing FreeBSD. |
![]() |
|
Thread Tools | Display Modes |
|
||||
![]()
Is the bridge a requirement? If ARP is the problem, it would go away if you were able to provision a solution without a bridge, and just forward IP packets where they are needed.
I understand you have multiple external IP addresses, so perhaps a bidirectional NAT (binat) configuration would enable you to provision em0 and re0 on separate Ethernets. |
|
||||
![]() Quote:
I am, however, warming up to the idea of doing it, because it'll allow the router to ... well... route. Sorta. I'm proposing a series of changes to my pf.conf that will look like this: Code:
vz_int = "em0" ext_int = "re1" int_int = "re0" host1_priv = "192.168.0.210" host1_pub = "XX.YY.ZZ.210" host2_priv = "192.168.0.211" host2_pub= "XX.YY.ZZ.211" # . # . # . # until host_11 # # NAT rules pass on $vz_int from $host1_priv to any binat-to $host1_pub pass on $vz_int from $host2_priv to any binat-to $host2_pub # . # . # . # until host_11 See this post for explanation. I'm going to have to change the NAT lines, and I think this will accomplish what I'm after? Code:
no nat on $ext_int from $local_ipv4_lan to $external_ipv4_lan nat on $vz_int from $local_ipv4_lan to any -> XX.YY.ZZ.221 |
|
||||
![]() Quote:
This is getting interesting and a little daunting. |
|
|||
![]()
What is the purpose of your setup? What are you trying to achieve?
Why did you choose this topology instead of a classic DMZ setup?
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
||||
![]()
Briefly, the only place I would suggest to use (bidirectional) NAT is on your external, public network. If the router is routing, rather than bridging, your external facing network is only attached to the router, and none of your servers would have an external address -- the mapping to Internet-facing addresses would be done by the router, and only the router.
--- J65nko reminds me that there are at least two "classic" DMZ topologies that might be considered, so I'll briefly describe them:
|
|
||||
![]() Quote:
So, I have 3 basic choices: 1. DMZ where each server is on the same broadcast domain as the .1 address, meaning the servers are wide open and it's up to their local packet filters (or whatever) to protect themselves. I'm not interested in DMZs, so that's not a consideration. 2. L3 Bridged Interface such as what I started this thread with: Bridge the ISP side and broadcast domain that my servers are on, and use PF (iptables in the case of Linux) on the router to protect the network. The router isn't routing in this case, it's just a pass-through. The servers still set their default routes to XX.YY.ZZ.1. 3. A binat setup where the server's have an RFC1918 address that gets 1-to-1 NAT'd to the public IPs that I own. In this case, every packet is routed (sort of... a NAT isn't really a router) through the router as opposed to bridged/passed-through. I'm doing choice #2 right now, but it's presenting me with all sorts of ARP problems on the FreeBSD router. The router is learning the ARPs for my IPs from the ISP's router, not from my servers. So the work-around for the time being is a collection of static ARPs on the router. What's important to note is that my router is also the termination point for my existing RFC1918 subnet (wireless network, NAS, etc). So packets from that LAN to the world need to be NAT'd. Packets from it to the public side of my network should not be NAT'd. And packets from the public side of my network to the private side should also not be NAT'd. If I go with choice #3, my concern is what will happen with the existing private LAN when it tries to talk to one of my public IPs? Will the right thing happen regarding the binat? |
|
||||
![]() Quote:
See the Redirection and Reflection section of the PF User's Guide. The chapter hasn't changed much since the fork, other than using different PF syntax. It does discuss DMZs, but not as a direct solution. http://www.openbsd.org/faq/pf/rdr.html#reflect Last edited by jggimi; 2nd December 2015 at 02:13 AM. Reason: clarity |
|
||||
![]() Quote:
![]() In a binat scenario, the router's interfaces:
Packets coming in re1 and destined to the Internet should be NAT'd via the last NAT rule I listed. The many-to-1. Packets coming in re1 and destined to XX.YY.ZZ.210 - .220 should not be many-to-1 NAT'd, but should trigger the 1-to-1 binat. This is where it gets confusing. Theoretically, if the router gets a packet destined for XX.YY.ZZ.210-.220 (the binat IPs) from any interface, it should know that it owns those 11 IPs, and do the binat appropriately. Correct? For instance, let's say I have the NAT'ing rules applied as previously posted. And... source: 192.168.100.10 destination: XX.YY.ZZ.210 The packet from 192.168.100.10 should hit interface re1, and then... what? Will the binat, which is sitting on interface em0, get triggered? Will the router know to send the packet, translated, to 172.16.0.210? Or will it just get dropped? |
|
||||
![]() Quote:
![]() |
|
||||
![]()
Most commonly, we use a split-horizon DNS. As an example, your authoritative nameserver would provide resolution for Internet-facing clients, and your caching nameserver would provide local resolution to local clients, resolving to your RFC1918 addresses.
|
|
||||
![]() Quote:
Thanks for your suggestions and guidance. |
|
||||
![]() Quote:
The basic steps: 1. Address the Verizon-facing interface on the router out of my static IP allotment, with the default route to .1 2. Address the public server facing interface on the router out of a completely phony IP block (I used 10.0.0.1/8). 3. Enable proxy arping on the router. In /etc/rc.conf: Code:
# Set Proxy ARP arpproxy_all="YES" Code:
# service routing restart Voila. It works. It's sad that I have to deploy a broken network technology to fix a broken network. Yay Verizon! |
![]() |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
FreeBSD NGINX issue | scrummie02 | FreeBSD Ports and Packages | 6 | 13th February 2015 09:33 PM |
Redundant Bridging and STP | igy01 | OpenBSD General | 5 | 23rd January 2013 11:40 PM |
vsftpd port issue on FreeBSD 8.2 x64 | sparky | FreeBSD Ports and Packages | 7 | 29th March 2012 11:50 AM |
FreeBSD FreeBSD 8 is getting new routing architecture | clone | News | 0 | 10th November 2009 06:38 PM |
FreeBSD ping issue | wooki | FreeBSD General | 1 | 2nd October 2009 04:10 PM |