Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

25.9. Required network setup for IPSec

There are some considerations you must ensure are correct before running FreeS/WAN software. These considerations are important if you don't want to receive error messages during start up of your VPN. The following are required:

You will need to enable TCP/IP forwarding on the both gateway servers. In Red Hat Linux, this is accomplished by changing or adding the following line, depending on the Red Hat version you use:

Version 6.1 only

Edit the network file, vi /etc/sysconfig/network, and change the following line:
FORWARD_IPV4="false"
To read:
FORWARD_IPV4="yes"

You must restart your network for the change to take effect:
[root@deep] /# /etc/rc.d/init.d/network restart

Bringing up interface lo		[  OK  ]
Bringing up interface eth0	        [  OK  ]
Bringing up interface eth1	        [  OK  ]

Version 6.2 only

To enable IPv4 forwarding on your RH 6.2 system, use the following command: Edit the /etc/sysctl.conf file and add the following line:
# Enable packet forwarding
net.ipv4.ip_forward = 1

You must restart your network for the change to take effect. The command to restart the network is the following:
[root@deep] /# /etc/rc.d/init.d/network restart

Setting network parameters		[  OK  ]
Bringing up interface lo		[  OK  ]
Bringing up interface eth0	        [  OK  ]
Bringing up interface eth1	        [  OK  ]

Recall that automatically keyed connections use keys automatically generated by the Pluto key negotiation daemon. The pluto daemon will start up, try to connect to the Pluto daemon at the other end of the tunnel, and establish a connection. For this reason, an IPSEC gateway should have packet filters rules in the firewall script file permitting the following protocols to traverse the gateway when talking to other IPSEC gateway:

  1. UDP port 500 for IKE implemented by the Pluto daemon

  2. Protocol 50 for ESP encryption and/or authentication

  3. Protocol 51 for AH packet-level authentication

  1. Edit the firewall script file, vi /etc/rc.d/init.d/firewall on both gateway machines, and add/check the following lines to allow IPSEC packets to traverse the remote network gateway to your network gateway and vice versa:
        # FreeS/WAN IPSec VPN
        # -------------------
        # If you are using the FreeSWAN IPSec VPN, you will need to fill in the
        # addresses of the gateways in the IPSECSG and the virtual interfaces for
        # FreeS/Wan IPSEC in the FREESWANVI parameters. Look at the beginning of
        # this firewall script rules file to set the parameters.
        # IPSECSG is a Space separated list of remote gateways. FREESWANVI is a
        # Space separated list of virtual interfaces for FreeS/Wan IPSEC
        # implementation. Only include those that are actually used.
        # Allow IPSEC protocol from remote gateways on external interface
        # IPSEC uses three main types of packet:
        # IKE uses the UDP protocol and port 500,
        # ESP use the protocol number 50, and
        # AH use the protocol number 51
        ipchains -A input  -i $EXTERNAL_INTERFACE -p udp \
                 -s $IPSECSG -j ACCEPT
        ipchains -A output  -i $EXTERNAL_INTERFACE -p udp \
                 -d $IPSECSG -j ACCEPT
        ipchains -A input  -i $EXTERNAL_INTERFACE -p 50 \
                 -s $IPSECSG -j ACCEPT
        ipchains -A output  -i $EXTERNAL_INTERFACE -p 50 \
                 -d $IPSECSG -j ACCEPT
        ipchains -A input  -i $EXTERNAL_INTERFACE -p 51 \
                 -s $IPSECSG -j ACCEPT
        ipchains -A output  -i $EXTERNAL_INTERFACE -p 51 \
                 -d $IPSECSG -j ACCEPT
        # Allow all traffic to FreeS/WAN Virtual Interface
        ipchains -A input  -i $FREESWANVI \
                 -s $ANYWHERE \
                 -d $ANYWHERE -j ACCEPT
        ipchains -A output  -i $FREESWANVI \
                 -s $ANYWHERE \
                 -d $ANYWHERE -j ACCEPT
        # Forward anything from the FreeS/WAN virtual interface IPSEC tunnel
        ipchains -A forward  -i $FREESWANVI \
                 -s $ANYWHERE \
                 -d $ANYWHERE -j ACCEPT
    
    where

    EXTERNAL_INTERFACE="eth0"

    You external interface to the Internet.

    ANYWHERE="any/0"

    Mean everywhere 0.0.0.0/0.

    IPSECSG=208.164.186.2

    Space separated list of remote VPN gateways.

    FREESWANVI=ipsec0

    Space separated list of virtual interfaces for FreeS/Wan.

    Important: See Networking Firewall, for more information. Dont forget to add/check these firewall rules in the other gateway as well.

  2. The rp_filter subsystem related to IP spoofing protection must be turned off on both gateways for IPSEC to work properly. This is accomplished by checking if the value 0 (off) is set in the /proc/sys/net/ipv4/conf/ipsec0/rp_filter and /proc/sys/net/ipv4/conf/eth0/rp_filter files respectively:

    1. To check if the value 0 (off) is set in the rp_filter files, use the commands:
      [root@deep] /# cat /proc/sys/net/ipv4/conf/ipsec0/rp_filter
      
      
0
      
      [root@deep] /# cat /proc/sys/net/ipv4/conf/eth0/rp_filter
      
      
0
      

      Important: The subdirectory ipsec0 in our example will be created only after the reboot of your system. So you may check the value of the rp_filter file in the ipsec0 directory after your system has been restarted.

    2. To set the value 0 (off) in the both rp_filter files manually, use the command:
      [root@deep] /# echo 0 > /proc/sys/net/ipv4/conf/ipsec0/rp_filter
      [root@deep] /# echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
      

      Tip: Also you can put lines like the following in your firewall script files /etc/rc.d/init.d/firewall on the both gateways to automatically set these values to 0 (off) and avoid making them manually:
          # Disable IP spoofing protection to allow IPSEC to work properly
          echo 0 > /proc/sys/net/ipv4/conf/ipsec0/rp_filter
          echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
          

  3. Note: In the example of the firewall script file above, we assume that eth0 is the interface you use for your connection. Of course if you use eth1 you must change eth0 to eth1, and so on.

    If you forget this step you will receive error messages on your terminal such as the following during the start up of FreeSWAN IPSEC:
    
ipsec_setup: WARNING: ipsec0 has route filtering turned on, KLIPS may not work
    ipsec_setup:  (/proc/sys/net/ipv4/conf/ipsec0/rp_filter = `1', should be 0)
    ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work
    ipsec_setup:  (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0)
    

  4. It's important to note that any masquerading rules for internal networks that use IPSEC must come after the rules allowing IPSEC related traffic (The step 2 and 3 above), or the machine will try to masquerade the packets, instead of them being passed over to IPSEC. Edit the firewall script file, vi /etc/rc.d/init.d/firewall on both gateway machines and add/check the following lines to allow masqueraded packets to traverse the remote network gateway to your network gateway and vice versa:
    # Masquerade internal traffic.
        # All internal traffic is masqueraded externally.
        ipchains -A forward -i $EXTERNAL_INTERFACE -s $LOCALNET_1 -j MASQ
    
    Where

    EXTERNAL_INTERFACE="eth0"

    You external interface to the Internet.

    LOCALNET_1=" 192.168.1.0/24"

    whatever private range you use.

Note: See Networking Firewall with Masquerading and Forwarding support for more information.

Now, you can reboot your system, and the machines on Gateway A should be able to talk to the machines on Gateway B with no problems.

 
 
  Published under the terms of the Open Publication License Design by Interspire