Wireless action
We needed to set up a point-to-point wireless bridge between two locations at a site for work. The two locations were separated by slightly more than 1/4 mile. There were no geographical features in the way, but there was a large hangar building blocking direct line of sight, so we had to use a 3-point layout. They were arranged in a rough L shape, with the long leg of the L being just about 1/4 mile.
We figured we could use IPsec to secure it, since we didn't need to support any clients on the wireless network. Without the headache of getting multiple clients to support a given IPsec configuration, using this stronger encryption was preferable to relying on possibly flawed wireless encryption standards. And even if the IPsec stack we're using turns out to have a flaw, it's all software based, so it can be easily changed. Hardware based encryption doesn't have this luxury.
We decided to go with WG302 APs, and some ~2ft long 9db omni-directional antennas, which are supposed to give about a 1/2 mile radius. Considering the distances involved, this seemed plenty sufficient, even taking the line-of-sight issues into consideration. The antennas support a wide variety of mounting options, and we chose to pole-mount two of them. The third was mounted on the inside of a window frame that overlooks the target AP.
Because of the 3-point AP layout, configuration was a bit more complicated than the single point-to-point bridge mode. The two endpoints were set up with single endpoints -- specifying the mac address of the middle AP -- but the middle had to be set for multiple-point-to-point. This was merely a matter of putting in the two endpoint APs' mac addresses. Once all the proper configuration was done, we were able to ping every AP from any point in the bridge. That took care of the wireless network itself.
Next we had to set up the IPsec tunnel. We put a FreeBSD machine at each endpoint. We set them both to forward packets (so they could act as network gateways), created a tunnel with virtual addresses, and set up IPsec policy to encrypt anything going to/from those virtual addresses. Now we could ping from one gateway to the other gateway's virtual tunnel address, and it would go across the network encrypted.
The final step was getting the gateways to route traffic between their respective wired networks. The gateways were called pwep1 and pwep2. Each one was hooked up to a different LAN segment; pwep1 was attached to 10.1.4.0/24, and pwep2 was attached to 10.1.2.0/24. Getting the 10.1.4.0/24 segment to know about 10.1.2.0/24 was trivial, as pwep1 was also the default route for all computers on that LAN segment. Once that gateway knew how to route to 10.1.2.0/24, all the computers could take advantage of it.
But on the other end, pwep2 was not 10.1.2.0/24's default gateway. In fact, that LAN segment was broken up into two subnets, and each one had its own default gateway (and those two gateways were connected with a VPN, but that's a different story). In order to get it to work, we'd have to set both of the 10.1.2.0/24 default gateways to route through pwep2 to access 10.1.4.0/24. This didn't seem like an ideal solution.
So we used NAT. We set pwep1 to use pwep2 as its default gateway; any networks it didn't know how to route directly would be piped on over. Then we set pwep2 to NAT anything coming in from pwep1 to pwep2's 10.1.2.0/24 address. For any computers on the 10.1.2.0/24 network, all the traffic from the 10.1.4.0/24 network would appear to be coming directly from pwep2. Since pwep2 was already on the 10.1.2.0/24 network, all the machines would know how to route to it, and all was well with the world.
And the best part: it all works. After weeks of planning and implementing and solving problems along the way, it freaking works!
We figured we could use IPsec to secure it, since we didn't need to support any clients on the wireless network. Without the headache of getting multiple clients to support a given IPsec configuration, using this stronger encryption was preferable to relying on possibly flawed wireless encryption standards. And even if the IPsec stack we're using turns out to have a flaw, it's all software based, so it can be easily changed. Hardware based encryption doesn't have this luxury.
We decided to go with WG302 APs, and some ~2ft long 9db omni-directional antennas, which are supposed to give about a 1/2 mile radius. Considering the distances involved, this seemed plenty sufficient, even taking the line-of-sight issues into consideration. The antennas support a wide variety of mounting options, and we chose to pole-mount two of them. The third was mounted on the inside of a window frame that overlooks the target AP.
Because of the 3-point AP layout, configuration was a bit more complicated than the single point-to-point bridge mode. The two endpoints were set up with single endpoints -- specifying the mac address of the middle AP -- but the middle had to be set for multiple-point-to-point. This was merely a matter of putting in the two endpoint APs' mac addresses. Once all the proper configuration was done, we were able to ping every AP from any point in the bridge. That took care of the wireless network itself.
Next we had to set up the IPsec tunnel. We put a FreeBSD machine at each endpoint. We set them both to forward packets (so they could act as network gateways), created a tunnel with virtual addresses, and set up IPsec policy to encrypt anything going to/from those virtual addresses. Now we could ping from one gateway to the other gateway's virtual tunnel address, and it would go across the network encrypted.
The final step was getting the gateways to route traffic between their respective wired networks. The gateways were called pwep1 and pwep2. Each one was hooked up to a different LAN segment; pwep1 was attached to 10.1.4.0/24, and pwep2 was attached to 10.1.2.0/24. Getting the 10.1.4.0/24 segment to know about 10.1.2.0/24 was trivial, as pwep1 was also the default route for all computers on that LAN segment. Once that gateway knew how to route to 10.1.2.0/24, all the computers could take advantage of it.
But on the other end, pwep2 was not 10.1.2.0/24's default gateway. In fact, that LAN segment was broken up into two subnets, and each one had its own default gateway (and those two gateways were connected with a VPN, but that's a different story). In order to get it to work, we'd have to set both of the 10.1.2.0/24 default gateways to route through pwep2 to access 10.1.4.0/24. This didn't seem like an ideal solution.
So we used NAT. We set pwep1 to use pwep2 as its default gateway; any networks it didn't know how to route directly would be piped on over. Then we set pwep2 to NAT anything coming in from pwep1 to pwep2's 10.1.2.0/24 address. For any computers on the 10.1.2.0/24 network, all the traffic from the 10.1.4.0/24 network would appear to be coming directly from pwep2. Since pwep2 was already on the 10.1.2.0/24 network, all the machines would know how to route to it, and all was well with the world.
And the best part: it all works. After weeks of planning and implementing and solving problems along the way, it freaking works!