[Openswan Users] MySQL over Openswan VPN tunnel

Christopher Slagel chris at noxsolutions.com
Thu Feb 13 12:16:26 EST 2014


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> 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> 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> 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> 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
>>>>>>>  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
>>>>>>>  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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>  
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20140213/20c24ff6/attachment.html>


More information about the Users mailing list