Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have searched for a solution for this problem for a few days now and cannot seem to find anything close to my situation (server is always NAT'd and clients are sometimes NAT'd).

I am trying to create a VPN server (CentOS 6.5) to host a VPN so I can stay connected. My server sits behind a Cisco 3825 who gets it's WAN IP via Verizon FiOS (DHCP).

The server's IP is 10.10.250.211/24 and I would like VPN'd users to use IP addresses in the 10.10.251.0/24 subnet.

The traffic makes it into my network via Cisco static NAT (so I know the router isn't the issue):

ip nat inside source static udp 10.10.250.211 500 interface GigabitEthernet0/0 500
ip nat inside source static udp 10.10.250.211 4500 interface GigabitEthernet0/0 4500
ip nat inside source static udp 10.10.250.211 1701 interface GigabitEthernet0/0 1701

/etc/ipsec.conf:

version 2.0     # conforms to second version of ipsec.conf specification
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.10.250.0/24

conn L2TP-PSK
       authby=secret
       pfs=no
       auto=add
       keyingtries=3
       rekey=no
       type=transport
       forceencaps=yes
       right=%any
       rightsubnet=10.10.251.0/24
       rightprotoport=17/0
       left=%defaultroute
       leftprotoport=17/%any
       dpddelay=10
       dpdtimeout=90
       dpdaction=clear

/etc/ppp/options.xl2tpd:

ipcp-accept-local
ipcp-accept-remote
ms-dns  10.10.250.213
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
logfile /var/log/ppp.log

/etc/xl2tpd/xl2tpd.conf:

[global]
listen-addr = 10.10.250.211
;
; requires openswan-2.5.18 or higher - Also does not yet work in combination
; with kernel mode l2tp as present in linux 2.6.23+
ipsec saref = yes
; Use refinfo of 22 if using an SAref kernel patch based on openswan 2.6.35 or
;  when using any of the SAref kernel patches for kernels up to 2.6.35.
; saref refinfo = 30
;
force userspace = yes
;
; debug tunnel = yes

[lns default]
ip range = 10.10.210.100-10.10.251.199
local ip = 10.10.251.1
; require chap = yes
refuse pap = yes
require authentication = yes
name = h3rrmillerVPN
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Unfortunately the pluto logs are somewhat cryptic (to me, anyway):

packet from 198.228.227.72:35280: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
packet from 198.228.227.72:35280: received Vendor ID payload [RFC 3947] method set to=109
packet from 198.228.227.72:35280: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method
109
packet from 198.228.227.72:35280: ignoring Vendor ID payload [FRAGMENTATION]
packet from 198.228.227.72:35280: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
packet from 198.228.227.72:35280: ignoring Vendor ID payload [Vid-Initial-Contact]
packet from 198.228.227.72:35280: ignoring Vendor ID payload [IKE CGA version 1]
"L2TP-PSK"[1] 198.228.227.72 #1: responding to Main Mode from unknown peer 198.228.227.72
"L2TP-PSK"[1] 198.228.227.72 #1: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
"L2TP-PSK"[1] 198.228.227.72 #1: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
"L2TP-PSK"[1] 198.228.227.72 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"L2TP-PSK"[1] 198.228.227.72 #1: STATE_MAIN_R1: sent MR1, expecting MI2
"L2TP-PSK"[1] 198.228.227.72 #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
"L2TP-PSK"[1] 198.228.227.72 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
"L2TP-PSK"[1] 198.228.227.72 #1: STATE_MAIN_R2: sent MR2, expecting MI3
"L2TP-PSK"[1] 198.228.227.72 #1: Main mode peer ID is ID_IPV4_ADDR: '172.20.10.2'
"L2TP-PSK"[1] 198.228.227.72 #1: switched from "L2TP-PSK" to "L2TP-PSK"
"L2TP-PSK"[2] 198.228.227.72 #1: deleting connection "L2TP-PSK" instance with peer 198.228.227.72 {isakmp=#0/ipsec=#0}
"L2TP-PSK"[2] 198.228.227.72 #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
"L2TP-PSK"[2] 198.228.227.72 #1: new NAT mapping for #1, was 198.228.227.72:35280, now 198.228.227.72:58327
"L2TP-PSK"[2] 198.228.227.72 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakl
ey_sha group=modp2048}
"L2TP-PSK"[2] 198.228.227.72 #1: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
"L2TP-PSK"[2] 198.228.227.72 #1: the peer proposed: 74.107.96.224/32:17/0 -> 172.20.10.2/32:17/0
"L2TP-PSK"[2] 198.228.227.72 #1: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
"L2TP-PSK"[2] 198.228.227.72 #2: responding to Quick Mode proposal {msgid:01000000}
"L2TP-PSK"[2] 198.228.227.72 #2:     us: 10.10.250.211[+S=C]:17/%any
"L2TP-PSK"[2] 198.228.227.72 #2:   them: 198.228.227.72[172.20.10.2,+S=C]:17/0===10.10.251.0/24
"L2TP-PSK"[2] 198.228.227.72 #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
"L2TP-PSK"[2] 198.228.227.72 #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
"L2TP-PSK"[2] 198.228.227.72 #2: netlink_raw_eroute: WARNING: that_client port 0 and that_host port 58327 don't match. Using that_
client port.
"L2TP-PSK"[2] 198.228.227.72 #2: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
"L2TP-PSK"[2] 198.228.227.72 #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
"L2TP-PSK"[2] 198.228.227.72 #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x3d587759 <0x58e5ad8a xfrm=AES_128
-HMAC_SHA1 NATOA=172.20.10.2 NATD=198.228.227.72:58327 DPD=none}
"L2TP-PSK"[2] 198.228.227.72 #1: the peer proposed: 74.107.96.224/32:17/0 -> 172.20.10.2/32:17/0
"L2TP-PSK"[2] 198.228.227.72 #1: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
"L2TP-PSK"[2] 198.228.227.72 #3: responding to Quick Mode proposal {msgid:02000000}
share|improve this question

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.