If you reboot a system with ipsec_enable="YES" uncommented, and your /etc/nf configuration file is faulty, the system will not completely boot up. It is important to get a working IPSec configuration before one enables ipsec_enable="YES" in /etc/rc.conf. Note that in both cases I have commented out ipsec_enable="YES" for the moment.
They are mirror images of the entries for the sensor. Next I set up the gif interfaces for this end of the tunnel. For example, a connection to port 8080 TCP on the gateway's external IP would be sent to the internal system 192.168.1.10. I have commented out a natd_flags line showing how to do port forwarding. I also enable NAT, with em0 being the Internet-facing interface with the external public IP address. Here is the gateway's additions to /etc/rc.conf: The static_routes and route_gif0_0 statements tell the sensor how to reach the backend network. The ifconfig_gif0 statement sets up the tunnel, with 10.4.12.10 as the local endpoint and 10.4.12.1 as the remote endpoint. The gifconfig statement defines the public IPs used as the tunnel endpoints. Here is the sensor's additions to /etc/rc.conf: Next I modify the /etc/rc.conf on each system to add support for IPSec and the gif tunnel. The last two lines are completely optional, but the IPFIREWALL_DEFAULT_TO_ACCEPT means I don't need to add rules to permit later traffic: Here is what I add to the gateway's kernel config file before recompiling the kernel. Here is what I add to the sensor's kernel config file before recompiling the kernel: The first step is to recompile the kernels of the sensor and gateway to suit their roles. The gateway will take care of connecting the two endpoints. The sensor will communicate with 192.168.1.10 when it needs to talk to the backend. The monitoring backend will communicate with 10.4.12.10 when it needs to talk to the sensor. Here is the architecture, with gif tunnels added: This will create an IP-in-IP tunnel, which I will then wrap inside IPSec ESP. One answer to this problem, and the approach I use, is to create a virtual tunnel from the sensor to the gateway, through which traffic to and from the backend can pass. All boxes in this scenario run FreeBSD 5.3 RELEASE. That backend internal private IP address is transformed using NAT on the VPN concentrator and NAT gateway. I would much rather use IPSec, since that can carry any communications between the sensor and the backend.Ĭomplicating matters, I need to communicate between a sensor with a public management IP and a backend with an internal private IP address. I don't like to use OpenSSH port forwarding or Stunnel because I must set up a separate port forwarding or tunnel session for each channel. This can involve multiple individual sockets.
I need to encrypt communications from the sensor to the monitoring backend. That document also references commands that no longer exist in FreeBSD 5.3, like 'gifconfig.' My architecture looks like this (all IP addresses are obfuscated):
Although the FreeBSD Handbook offers a VPN over IPSec section, it doesn't describe the scenario I face when deploying network security monitoring sensors.
0 kommentar(er)
