[Openswan Users] New User Question
Neal Murphy
neal.p.murphy at alum.wpi.edu
Wed May 29 16:50:05 UTC 2013
On Wednesday, May 29, 2013 11:15:01 AM Matt Smith wrote:
> Hello - I hopefully have a simple question here. Config first running
> on Ubuntu 12.04.
>
> # ipsec.conf
> version 2.0
> config setup
> dumpdir=/var/run/pluto/
> nat_traversal=yes
>
> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25
> .0.0.0/8,%v6:fd00::/8,%v6:fe80::/10 oe=off
> protostack=auto ### Should this be set to a static value?
>
> conn apps
> authby=secret # for example here only
> type=transport
> left=192.168.136.96
> right=192.168.151.58
> auto=start
>
> # left ifconfig
> eth0 Link encap:Ethernet HWaddr xx:xx:xx:ae:16:16
> inet addr:xxx:xxx:xxx.89 Bcast:xxx:xxx:xxx.255
> Mask:255.255.255.0 inet6 addr: ... Scope:Global
> inet6 addr: ... Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:404077 errors:0 dropped:0 overruns:0 frame:0
> TX packets:390334 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:82485572 (82.4 MB) TX bytes:123162781 (123.1 MB)
> Interrupt:76
>
> eth0:0 Link encap:Ethernet HWaddr xx:xx:xx:ae:16:16
> inet addr:192.168.136.96 Bcast:192.168.255.255
> Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1xx
> Interrupt:76
>
> # right ifconfig
> eth0 Link encap:Ethernet HWaddr xx:xx:xx:70:de:2b
> inet addr:xxx:xxx:xxx.94 Bcast:xxx:xxx:xxx.255
> Mask:255.255.255.0 inet6 addr: ... Scope:Global
> inet6 addr: ... Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:375204 errors:0 dropped:0 overruns:0 frame:0
> TX packets:355379 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:80206680 (80.2 MB) TX bytes:41922744 (41.9 MB)
> Interrupt:76
>
> eth0:0 Link encap:Ethernet HWaddr xx:xx:xx:70:de:2b
> inet addr:192.168.151.58 Bcast:192.168.255.255
> Mask:255.255.128.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Interrupt:76
>
> I have two VPSs on the same datacenter local, private network. They
> offer some protection for communications between machines, but I would
> like to encrypt all data sent on the local network. This configuration
> seems to work. I can read plain text transmissions before starting the
> ipsec daemons, but afterword traffic moves to a different port than I
> set the TCP server to listen on -- so I assume things are working. Is
> there a better way to check things are working? (Not my main
> question.)
>
> My test program sends data from the right to 192.168.136.96:5001. It
> (test program) works if both daemons are off (unencrypted) or both
> daemons are on. How do I assure that transmission will fail, the
> transport is not up (on both sides, esp. the sending side)?
>
> Can I set up some iptables rules? Note: This seems to be further
> complicated because I have to use a virtual interface (eth0:0) for the
> local traffic.
>
> I have seen rules like this:
> iptables -A POSTROUTING -t nat -d 192.168.1.0/24 -o eth0 -m policy
> --dir out --pol ipsec -j ACCEPT
> iptables -A INPUT -m policy --dir in --pol ipsec -j ACCEPT
> iptables -A INPUT -p udp -m multiports --dports 500,4500 -j ACCEPT
> iptables -A INPUT -p esp -j ACCEPT
> iptables -A FORWARD -m policy --dir in --pol ipsec -j ACCEPT
>
> I believe what those iptables rules are doing, but I could not have
> come up with them on my own at this point, so I want to make sure a
> translation of them would be appropriate. If they are appropriate,
> would I just need to make the POSTROUTING rule match the destination
> address of the remote box (or probably more ideally the entire private
> network)? And add appropriate DROP statements for POSTROUTING, INPUT
> and FORWARD?
>
> What are my options to make sure I don't send unencrypted data?
Unless you are using a very old version of Linux, virtual interfaces should be
extinct. Today, an IF can have one or more primary addresses, each with zero
or more secondary addresses. (The first address in a LAN added becomes the
primary address; all other addrs in that LAN added later become secondary
addresses.)
To address your issue, something like the following should guarantee that only
IPSEC traffic passes between the two private addresses. Reverse the -d and -s
addrs for the other host. It neither addresses nor affects any other traffic.
-N chkPrivate
-A chkPrivate -p esp -j ACCEPT
-A chkPrivate -p udp -m multiports --ports 500,4500 -j ACCEPT
-A chkPrivate -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 192.168.151.58 -d 192.168.136.96 -j chkPrivate
-A OUTPUT -s 192.168.136.96 -d 192.168.151.58 -j chkPrivate
N
More information about the Users
mailing list