[Openswan Users] MySQL over Openswan VPN tunnel

Simon Deziel simon at xelerance.com
Thu Feb 13 17:00:30 EST 2014


Hi Christopher,

I'm glad to hear it worked. To make the changes permanent, on
RHEL/CentOS boxes, you can save the iptables rules by running:

  service iptables save

You can ensure iptables starts on boot (it does by default) with:

  chkconfig iptables on

As for the MTU changes, /etc/sysconfig/network-scripts/ifcfg-eth0 is the
right place.

For how PMTU works:
http://packetlife.net/blog/2008/aug/18/path-mtu-discovery/

HTH,
Simon

On 14-02-13 03:42 PM, Christopher Slagel wrote:
> Well, I had tried this before but I must have messed it up, but I ran the
> iptables commands on both ends and were in business!
> 
> Can you give me a rundown on what exactly this is doing?  And how do I
> make this persistent through reboot?
> 
> Thanks so much! 
> 
> 
> 
> On 2/13/14, 11:02 AM, "Simon Deziel" <simon at xelerance.com> wrote:
> 
>> 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