Re: IPSec VPN docs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mark Haney wrote:

I'm trying to get a VPN setup between my FC1 box at home and a DLink DFL300 at my office so I can do some things securely without having to make the 30 minute drive in to work to fix stuff. I've googled the subject and the amount of documentation is pretty immense. Can someone give me a shortened version what I need to configure or point me to a good step by step doc on how to do it?

The easiest way to configure ipsec vpn and still keep kernel maintenance simple is by using the 2.6 kernel. Follow notes elsewhere on how to migrate to the 2.6 kernel, and hopefully the attached note will help you from there. It is a work in progress.

--
-----------------------------------------------------------
  "Spend less!  Do more!  Go Open Source..." -- Dirigo.net
  Chris Johnson, RHCE #807000448202021

These are notes on how I configured ipsec using the Fedora Core with kernel 2.6.3-2.1.240 (needs to be at least build 238 to avoid kernel panics!).  I also installed the ipsec-tools-0.2.2-8 rpm from Fedora Core 2 test1.

In transport mode over 11MB/s wireless without wep, I transferred 15MB between a couple of athlon systems, utilizing about 30% of cpu on Mobile AMD Athlon(tm) XP2600+ to achieve 3.8Mbps throughput.

If SRCNET or DSTNET are configured then the ipsec connection will be tunnel mode, otherwise it will be transport mode.

NOTE: The SRCGATEWAY and DSTGATEWAY referenced in RHEL 3 manual are not supported by the FC ifup-ipsec script as of initscripts-7.46-1.


------- START ifcfg-ipsec0 --------
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
ONBOOT=no
USERCTL=yes
TYPE=IPSEC
IKE_METHOD=PSK
#SRCNET=172.16.0.0/16
#DSTNET=192.168.0.0/16
SRC=10.0.0.124
DST=10.0.0.11
------- END ifcfg-ipsec0 --------

------- START keys-ipsec0 --------
IKE_PSK=yourPreSharedSecretMatchingAtBothEndpoints
------- END keys-ipsec0 --------

Some alterations to iptables are necessary to permit ipsec communication:
------- START iptables addition to allow ipsec communication --------
# Under the *filter table section:
# These should be further restricted to ipsec partner addresses and their inbound interfaces.
# Allow ipsec esp, ah
-A INPUT -p 50 -j ACCEPT
-A INPUT -p 51 -j ACCEPT
# Allow isakmp initiated by others.
# Responses to my isakmp initiation are permitted by '--state ESTABLISHED -j ACCEPT' above.
-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
------- END iptables addition to allow ipsec communication --------



The following iptables additions are samples of how to control packets that come through an ipsec tunnel. Any ipsec ESP tunneled packets from a.b.c.d are marked with a "1" in the mangle table.  Likewise those from e.f.g.h are marked with a "2".

Once decrypted those packets keep their marks, and rules in the INPUT and/or FORWARD chains of the filter table (as appropriate) use those marks to send them through additional chains.

In the following examples vpn 1 packets to x.x.x.x:80 are accepted, but other packets return from the check_vpn_1 chain and are subjected to the same rules as non-tunneled packets. vpn 2 packets to y.y.y.y:5900 are accepted, but other packets are rejected.

NOTE: Transport mode packets never hit the *filter table unencrypted so this only works for tunnel mode packets. :(
------- START iptables addition restricting ipsec tunneled packets --------
# Under the *mangle table section:
# Mark packets that come in through IPSEC tunnels
-A PREROUTING -i eth1 -p 50 -s a.b.c.d/32 -j MARK --set-mark 1
-A PREROUTING -i eth1 -p 50 -s e.f.g.h/32 -j MARK --set-mark 2

# Under the *filter table section:
                                                                                
# ------- 'check_vpn_1' chain -------
-N check_vpn_1
-A check_vpn_1 -m state --state NEW -p tcp -m tcp -d x.x.x.x/32 --dport 80 -j LOG --log-prefix IPTABLES_DIRIGO_VPN_OK:
-A check_vpn_1 -m state --state NEW -p tcp -m tcp -d x.x.x.x/32 --dport 80 -j ACCEPT
# ------- end of 'check_vpn_1' chain -------

# ------- 'check_vpn_2' chain -------
-N check_vpn_2
-A check_vpn_2 -m state --state NEW -p tcp -m tcp -d y.y.y.y/32 --dport 5900 -j LOG --log-prefix IPTABLES_DNINJ_VPN_OK:
-A check_vpn_2 -m state --state NEW -p tcp -m tcp -d y.y.y.y/32 --dport 5900 -j ACCEPT
-A check_vpn_2 -j REJECT
# ------- end of 'check_vpn_2' chain -------

# What we check and allow coming through ipsec
-A INPUT -m mark --mark 1 -j check_vpn_1
-A INPUT -m mark --mark 2 -j check_vpn_2
-A INPUT -m mark ! --mark 0/3 -j LOG --log-prefix IPTABLES_UNK_VPN:
------- END iptables addition restricting ipsec tunneled packets --------

Sample syslog output from VPN 1 based connection:
Mar  7 21:05:41 chris kernel: IPTABLES_DIRIGO_VPN_OK:IN=eth1 OUT= MAC=00:05:5d:f1:cb:ae:00:08:54:d0:9d:3d:08:00 SRC=192.168.0.254 DST=172.16.0.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=62334 DF PROTO=TCP SPT=32818 DPT=80 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0

Notice that once decrypted, as far as filter table rules are concerned IN=eth1, thus the interface the ESP packet came in is the apparent input interface of the tunnelled packet, and the source and destination addresses and ports are the same as if it were never encrypted.



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux