Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 10172 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

L2TP/IPSEC VPN with Cricketwireless

Jay Jay

Cricketwireless is a US based wireless carrier who piggyback's on att towers.

I have two vpn's set up, one based on openvpn using a 5 digit port #, the other L2TP w/ipsec. No issues connecting to the openvpn server using the phone (or laptop when tethered to the phone).

With the L2TP/ipsec things get more interesting. I can connect about 1 out of 20 times. Often toggling airplane mode then attempting to connect. Something odd I noticed as well.

Say the phone indicates it's pulling a public ip of x.y.173.2

I connected/disconnected 6x from the openvpn server.

Connection log indicates connection from the following ip's

x.y.172.88
x.y.172.96
x.y.172.72
x.y.172.80

Mind you, i'm not changing anything on the phone other than disconnecting and reconnecting to the vpn server.

With L2TP/ipsec things get more interesting.

2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.80:500: received Vendor ID payload [RFC 3947]
2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.80:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.80:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.80:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.80:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.80:500: received Vendor ID payload [Dead Peer Detection]
2018:04:14-22:10:30 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[2] x.y.172.80 #3: responding to Main Mode from unknown peer x.y.172.80
2018:04:14-22:10:30 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[2] x.y.172.80 #3: NAT-Traversal: Result using RFC 3947: peer is NATed
2018:04:14-22:10:30 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange
2018:04:14-22:10:33 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange
2018:04:14-22:10:36 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange
2018:04:14-22:10:37 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[2] x.y.172.80 #2: max number of retransmissions (2) reached STATE_MAIN_R2
2018:04:14-22:10:39 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange
2018:04:14-22:10:43 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange
2018:04:14-22:10:46 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange
2018:04:14-22:10:49 utm pluto[8213]: packet from x.y.172.104:4500: Main Mode message is part of an unknown exchange

 

 

Note the 2 different IP's above. If I didn't know better, I'd say each connection comes from a different IP. In the case of openvpn, only a single port is used, but with l2tp/ipsec, there's two connections in use to establish the tunnel and because the ip's differ, the server rejects them. At some point they are the same and the connection is made. Below is the log from a successful connection. Note the IP's for both ports match.

2018:04:14-22:18:56 utm pluto[8213]: packet from x.y.172.96:500: received Vendor ID payload [RFC 3947]
2018:04:14-22:18:56 utm pluto[8213]: packet from x.y.172.96:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2018:04:14-22:18:56 utm pluto[8213]: packet from x.y.172.96:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2018:04:14-22:18:56 utm pluto[8213]: packet from x.y.172.96:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2018:04:14-22:18:56 utm pluto[8213]: packet from x.y.172.96:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
2018:04:14-22:18:56 utm pluto[8213]: packet from x.y.172.96:500: received Vendor ID payload [Dead Peer Detection]
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[7] x.y.172.96 #8: responding to Main Mode from unknown peer x.y.172.96
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[7] x.y.172.96 #8: NAT-Traversal: Result using RFC 3947: peer is NATed
2018:04:14-22:18:56 utm pluto[8213]: | NAT-T: new mapping x.y.172.96:500/4500)
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[7] x.y.172.96:4500 #8: Peer ID is ID_DER_ASN1_DN: 'C=us, L=none, O=none, CN=USERACCOUNTLOGIN, E=remote@domain.com'
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[7] x.y.172.96:4500 #8: crl not found
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[7] x.y.172.96:4500 #8: certificate status unknown
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[8]x.y.172.96:4500 #8: deleting connection "L_for USERACCOUNTLOGIN"[7] instance with peer x.y.172.96 {isakmp=#0/ipsec=#0}
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[8]x.y.172.96:4500 #8: we have a cert and are sending it
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[8]x.y.172.96:4500 #8: Dead Peer Detection (RFC 3706) enabled
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[8]x.y.172.96:4500 #8: sent MR3, ISAKMP SA established
2018:04:14-22:18:56 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[8]x.y.172.96:4500 #8: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2018:04:14-22:18:57 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[1] x.y.172.96:4500 #9: responding to Quick Mode
2018:04:14-22:18:58 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[1] x.y.172.96:4500 #9: IPsec SA established {ESP=>0x02353016 <0x200ab672 NATOA=0.0.0.0 DPD}
2018:04:14-22:18:58 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[4] x.y.172.30 #5: max number of retransmissions (2) reached STATE_MAIN_R2
2018:04:14-22:18:58 utm pluto[8213]: "L_for USERACCOUNTLOGIN"[4] x.y.172.30: deleting connection "L_for USERACCOUNTLOGIN"[4] instance with peer x.y.172.30 {isakmp=#0/ipsec=#0}
2018:04:14-22:18:59 utm pppd-l2tp[9093]: Plugin aua.so loaded.
2018:04:14-22:18:59 utm pppd-l2tp[9093]: AUA plugin initialized.
2018:04:14-22:18:59 utm pppd-l2tp[9093]: Plugin ippool.so loaded.
2018:04:14-22:19:00 utm pppd-l2tp[9093]: Plugin pppol2tp.so loaded.
2018:04:14-22:19:00 utm pppd-l2tp[9093]: pppd 2.4.7 started by (unknown), uid 0
2018:04:14-22:19:00 utm pppd-l2tp[9093]: Using interface ppp0
2018:04:14-22:19:00 utm pppd-l2tp[9093]: Connect: ppp0 <-->
2018:04:14-22:19:00 utm pppd-l2tp[9093]: Overriding mtu 1500 to 1380
2018:04:14-22:19:00 utm pppd-l2tp[9093]: Overriding mru 1500 to mtu value 1380
2018:04:14-22:19:02 utm pppd-l2tp[9093]: Overriding mtu 1400 to 1380
2018:04:14-22:19:05 utm pppd-l2tp[9093]: Cannot determine ethernet address for proxy ARP
2018:04:14-22:19:05 utm pppd-l2tp[9093]: local IP address 10.123.3.1
2018:04:14-22:19:05 utm pppd-l2tp[9093]: remote IP address 10.123.3.2
2018:04:14-22:19:05 utm pppd-l2tp[9093]: id="2201" severity="info" sys="SecureNet" sub="vpn" event="Connection started" username="USERACCOUNTLOGIN" variant="l2tp" srcip="x.y.172.96" virtual_ip="10.123.3.2"

Using sim 2 (freedompop att lte) on the same phone these ip's remain consistent between the two ports. Cricket is doing some weird proxy ip shuffling. Problem with freedompop is they throttle non standard ports to almost nothing, so a vpn is useless unless its on port 80 or 443 or similar.

I further tested the IP cycling theory by pinging my firewall with the cricket connected phone. Firewall logs indicate ICMP requests from different ip' each time. The pool is not large, maybe 5 or 6 different ip's, but still they are different each time. However, the same IP is used for port 80/443 traffic (http/https).

Also seems like there's some deep packet inspection going on. Refreshing a site that shows your public ip a number of times returns the same ip. Telneting to the firewall's port 80 (which is blocked) using the cricket data connection shows a different ip in the firewall log each time.

Sneaky! So this is at least the why the vpn connection is failing to connect most of the time. Is there a work around...........? 



This thread was automatically locked due to age.
Parents
  • 0

    You found the workaround - OpenVPN. [;)]

    Seriously, if that's the way Cricket handles Internet connections, there's no hope with IPsec.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Am I correct in understanding that no VPN would work if portions of it are trying to connect using different IP's?

    Would IKEv2 fragmentation support apply in this case or that has nothing to do with fragmentation resulting from different ip's?

  • 0 in reply to Jay Jay

    I'd be interested in knowing what happens if you change the SSL VPN Protocol to UDP- don't forget to re-download the configuration.  Does that break the SSL VPN?

    I don't think there's any IPsec that will work with "floating" IPs, this is unrelated to IP fragmentation addressed by IKEv2.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Bob,


    SSL VPN (openvpn) was already set to use UDP.  I did test previously with TCP too.  Both work fine and at full speed (throttled to ~8mbps up/down).

    Looks like I'll just need to keep two clients on whatever devices I plan on using VPN with.  Issue I've had with openvpn in the past was not being able to utilize full bandwidth.  Given the cricket service is already throttled it's a nonissue.  When the remote is on a cable connection (150 mbps down or better), openvpn would top out around 40-60 mbps iirc (recall utm is on a symmetrical gigabit connection).  L2TP/ipsec would saturate it fully.  I started this thread because i've never seen this type of behavior with any service provider in the past...

  • 0 in reply to Jay Jay

    Agreed - it's strange behavior!

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    I have not performed the level of analysis performed by the OP, but I can confirm general end user problems performing L2TP and IPSEC connections from a Cricket Wireless phone cellular connection.  Android 7.0.  Connection works just fine from non cellular connection.  I will test more and report results as I have time.  

    For me thus far, the problem persists across any L2TP and IPSEC connection regardless of app used.

  • 0 in reply to Brandon E

    I believe that wireless providers block UDP and other ports that might be used for VPNs.  One reason to stay with the TCP 443 default for the SSL VPN is that your cellular data provider might block UDP.  My AT&T iPhone XS was unable to establish a working tunnel when using UDP 443 or UDP 1443.  Everything worked perfectly with TCP 443.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0 in reply to Brandon E

    I believe that wireless providers block UDP and other ports that might be used for VPNs.  One reason to stay with the TCP 443 default for the SSL VPN is that your cellular data provider might block UDP.  My AT&T iPhone XS was unable to establish a working tunnel when using UDP 443 or UDP 1443.  Everything worked perfectly with TCP 443.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data
Unfiltered HTML