[Openswan Users] Can Get Traffic and Respond from Our End, but Can't Send Data?

[Binal Patel]

Hi all,

I've been struggling with this for the past few days, was hoping to get
some help.

I have a VPN tunnel set up to a client to receive patient information via
messages. I've been able to receive them successfully, and when they're
received the software we use (Mirth) acknowledges them successfully to the
client. So the tunnel is up, and I am actively receiving and acknowledging
data from them when I receive it.

OpenSwan is installed on a Linux box on AWS. The Mirth software is
installed on another server within the same subnet. When trying to initiate
a connection the client's servers however, I receive a time out error, and
I cannot ping the client's servers from my end (even though the client says
there aren't any filters/blocking in place).

I suspect it's a routing issue? When I do tcpdump on the Mirth server, it
appears to be trying to directly connect to the client's server, without
going through the intermediary VPN tunnel. I'm attempting to initiate a
connection from the Mirth server with the 137.33.64.129 server within the
client's network.

Here's my configuration (replaced external IPs with random IPs).

# This file:  /usr/local/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5


version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # Do not set debug options to debug configuration issues!
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 dpd
private"
        # eg:
        #i plutodebug="control parsing"
        # Again: only enable plutodebug or klipsdebug when asked by a
developer
        #
        # enable to get logs per-peer
        plutoopts="--perpeerlog"
        #
        # Enable core dumps (might require system changes, like ulimit -C)
        # This is required for abrtd to work properly
        # Note: incorrect SElinux policies might prevent pluto writing the
core
        dumpdir=/var/run/pluto/
        #
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        nat_traversal=yes
        # exclude networks used on server side by adding %v4:!a.b.c.0/24
        # It seems that T-Mobile in the US and Rogers/Fido in Canada are
        # using 25/8 as "private" address space on their 3G network.
        # This range has not been announced via BGP (at least upto
2010-12-21)
        #virtual_private=%v4:174.0.0.0/24,%v4:!138.33.64.0/24
        # OE is now off by default. Uncomment and change to on, to enable.
        oe=off
        # which IPsec stack to use. auto will try netkey, then klips then
mast
        protostack=netkey
        # Use this to log to a file, or disable logging on embedded systems
(like openwrt)
        #plutostderrlog=/dev/null

# Add connections here

conn CLIENT
        type=tunnel
        authby=secret
        auto=start
        pfs=no
        ike=aes128-sha1
        phase2alg=aes128-sha1
        aggrmode=no
        ikelifetime=28800s
        salifetime=28800s
        left=%defaultroute
        leftid=59.35.345.248
        leftsubnets={174.0.0.248/32,174.0.0.247/32,174.0.0.246/32}
        right=200.25.64.23
        rightid=200.25.64.23
        rightsubnets={
137.33.64.129/32,137.33.64.130/32,137.33.64.131/32,137.33.64.132/32}
        rekey=yes
        dpdaction=hold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20160204/9f686544/attachment.html>