[Openswan Users] MySQL over Openswan VPN tunnel

Simon Deziel simon at xelerance.com
Thu Feb 13 14:02:06 EST 2014


Hi Christopher,

Using a transport mode connection only works if the connection you want
to secure is between 54.213.24.xxx and 72.26.103.xxx. If you need the
left|rightsubnet= lines that means you need a tunnel type.

That said, tunnel or transport shouldn't matter as as long as ICMP can
go through the clamp-mss-to-pmtu should work. Can you confirm if that's
the case?

Simon

On 14-02-13 12:16 PM, Christopher Slagel wrote:
> Hi Simon.  Both ends are set to allow ALL traffic from the other side.
> 
> I tried switching it to “transport” instead of “tunnel” and it didn’t
> seem to work, it all of a sudden said there was 30 open connections.
> 
> With that said, I have another openswan server for client VPN into our
> AWS environment (which uses transport) and everything works great
> through this.
> 
> Here’s the 2 different configuration files, maybe you can help me get
> them working similarly?
> 
> *Ipsec.conf for BOTH tunnel servers:*
> 
> # basic configuration
> config setup
>         # Debug-logging controls:  "none" for (almost) none, "all" for lots.
>         # klipsdebug=none
>         # plutodebug="control parsing"
>         # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
>         protostack=netkey
>         nat_traversal=yes
>         virtual_private=
>         oe=off
>         # Enable this if you see "failed to find any available worker"
>         # nhelpers=0
> 
> #You may put your configuration (.conf) file in the "/etc/ipsec.d/" and
> uncomment this.
> include /etc/ipsec.d/*.conf
> 
> */VPC1-to-colo tunnel conf/*
> 
> conn vpc1-to-DT
> type=tunnel
> authby=secret
> left=%defaultroute
> leftid=54.213.24.xxx
> leftnexthop=%defaultroute
> leftsubnet=10.1.4.0/24
> right=72.26.103.xxx
> rightsubnet=10.1.2.0/23
> pfs=yes
> auto=start
> 
> 
> */Colo-to-VPC1 tunnel conf/*
> 
> conn DT-to-vpc1
> type=tunnel
> authby=secret
> left=%defaultroute
> leftid=72.26.103.xxx
> leftnexthop=%defaultroute
> leftsubnet=10.1.2.0/23
> right=54.213.24.xxx
> rightsubnet=10.1.4.0/24
> pfs=yes
> auto=start
> 
> 
> */Client point VPN ipsec.conf/*
> 
> # basic configuration
> 
> config setup
> interfaces=%defaultroute
> klipsdebug=none
> nat_traversal=yes
> nhelpers=0
> oe=off
> plutodebug=none
> plutostderrlog=/var/log/pluto.log
> protostack=netkey
> virtual_private=%v4:10.1.4.0/24
> 
> conn L2TP-PSK
> authby=secret
> pfs=no
> auto=add
> keyingtries=3
> rekey=no
> type=transport
> forceencaps=yes
> right=%any
> rightsubnet=vhost:%any,%priv
> rightprotoport=17/0
> # Using the magic port of "0" means "any one single port". This is
> # a work around required for Apple OSX clients that use a randomly
> # high port, but propose "0" instead of their port.
> left=%defaultroute
> leftprotoport=17/1701
> # Apple iOS doesn't send delete notify so we need dead peer detection
> # to detect vanishing clients
> dpddelay=10
> dpdtimeout=90
> dpdaction=clear
> 
> 
> 
> 
> 
> On 2/13/14, 5:45 AM, "Simon Deziel" <simon at xelerance.com
> <mailto:simon at xelerance.com>> wrote:
> 
>     Hi Christopher,
> 
>     I just re-read your first message and noticed you are on Amazon which is
>     notorious to block ICMP and ESP by default.
> 
>     Recommendations of things to tweak:
> 
>     * Allow ICMP in the Security Groups of both sides
>     * Allow ICMP on both VMs (if using firewall)
>     * If using host to host IPsec, use transport mode instead of tunnel
>     * If on a VPC (as opposed to EC2), allow ESP in the Security Groups
> 
>     Once you have a path between the 2 VMs that is clear for ICMP, the
>     clamp-mss-to-pmtu will start working.
> 
>     HTH,
>     Simon
> 
>     On 14-02-12 10:47 PM, Simon Deziel wrote:
> 
>         Oups, sorry, this one should not complain:
>           iptables -t mangle -I POSTROUTING -p tcp --tcp-flags SYN,RST
>         SYN -j
>         TCPMSS --clamp-mss-to-pmtu
>         On 14-02-12 06:56 PM, Christopher Slagel wrote:
> 
>             Responds with the following:
> 
>             [root at noxmail1 ~]# iptables -I OUTPUT -p tcp -j TCPMSS
>             --clamp-mss-to-pmtu
>             iptables: Invalid argument. Run `dmesg' for more information.
> 
> 
> 
> 
> 
>             On 2/12/14, 3:25 PM, "Simon Deziel" <simon at xelerance.com
>             <mailto:simon at xelerance.com>> wrote:
> 
>                 You can try this:
> 
>                   iptables -I OUTPUT -p tcp -j TCPMSS --clamp-mss-to-pmtu
> 
> 
> 
> 
>                 On 14-02-12 06:17 PM, Christopher Slagel wrote:
> 
>                     Simon, as an update, it looks like it’s BETTER but
>                     still having some
>                     problems.  Small queries are now working, but
>                     anything over 1 row still
>                     seems to hang.  I’ve tried lowering the MTU a bit
>                     more a couple times
>                     and
>                     still no luck.
> 
> 
> 
> 
> 
>                     On 2/12/14, 12:56 PM, "Simon Deziel"
>                     <simon at xelerance.com <mailto:simon at xelerance.com>>
>                     wrote:
> 
>                         You can first try with running "sudo ifconfig
>                         eth0 mtu 1400" directly
>                         on
>                         the console. This setting will not survive a
>                         reboot of course.
> 
>                         On 14-02-12 03:53 PM, Christopher Slagel wrote:
> 
>                             Thanks Simon.  Through some research I found
>                             that that might be the
>                             issue,
>                             and I¹ve tried editing our
>                             /etc/sysconfig/network-scripts/ifcfg-eth0
>                             files
>                             and messing with the MTU (adding MTU=³xyz²),
>                             but don¹t seem to be
>                             having
>                             any success.  Is there another way I should
>                             try messing with the MTU?
> 
> 
> 
>                             On 2/12/14, 12:50 PM, "Simon Deziel"
>                             <simon at xelerance.com
>                             <mailto:simon at xelerance.com>> wrote:
> 
>                                 Hi Christopher,
> 
>                                 The problem you describe could well be
>                                 related to a MTU issue. I'd
>                                 try
>                                 setting a MTU of say 1400 and see if
>                                 things start working.
> 
>                                 HTH,
>                                 Simon
> 
>                                 On 14-02-12 03:38 PM, Christopher Slagel
>                                 wrote:
> 
>                                     We have a VPN tunnel with Openswan
>                                     between two AWS regions and our
>                                     colo
>                                     facility (Used AWS¹s
>                                     guide:
>                                     http://aws.amazon.com/articles/5472675506466066).  Regular
>                                     usage
>                                     works OK, but we are having some
>                                     MySQL issues over the tunnel
>                                     between
>                                     all areas.  Using mysql command line
>                                     client on a linux server works,
>                                     but
>                                     trying to connect using the MySQL
>                                     Connector J it basically stallsŠ
>                                     it
>                                     seems to open the connection, but
>                                     then gets stuck.  It doesn't get
>                                     denied or anything, just hangs
>                                     there.  Logging isn¹t picking up
>                                     anything
>                                     at all and usually very verbose
>                                     about errors.  Any input as to what
>                                     we
>                                     can do to fix this/improve the
>                                     connections would be appreciated.
>                                     Thanks.
> 
> 
> 
>                                     _______________________________________________
>                                     Users at lists.openswan.org
>                                     <mailto:Users at lists.openswan.org>
>                                     https://lists.openswan.org/mailman/listinfo/users
>                                     Micropayments:
>                                     https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>                                     Building and Integrating Virtual
>                                     Private Networks with Openswan:
> 
> 
>                                     http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283
>                                     15
>                                     5
> 
> 
>                                 _______________________________________________
>                                 Users at lists.openswan.org
>                                 <mailto:Users at lists.openswan.org>
>                                 https://lists.openswan.org/mailman/listinfo/users
>                                 Micropayments:
>                                 https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>                                 Building and Integrating Virtual Private
>                                 Networks with Openswan:
> 
> 
>                                 http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=2831
>                                 55
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



More information about the Users mailing list