Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hanuszewski]

What am I suppose to use for L2TP Mode on the DSR-250? Client, Gateway, or None

>Gateway< sounds most plausible to me.

We are having a planned network outage tonight so I wont be able to try anything until tomorrow. But just so I understand, this is a good learning experience, my phone, computer, tablet, etc. would be clients and the DSR-250 would be the gateway to my network.

I was reading up on mode config, I get that it allows the gateway to push some configuration options to the clients. Should I enable this or is it not necessary because i'm just using IPSec as the tunnel for L2TP. With mode config I have to set the  IPs in the 192.168.1.0 range since the DSR-250 is on the 192.168.0.0 range. All the machines on my network are also on the 192.168.0.0 range.

Also I built a Windows 7 VM. Just can't test it yet. lol.

Thanks

[PacketTracer]

config mode and xauth both are proprietary Cisco extension to IKEv1 to compensate for missing features in IKEv1 - but they are de facto standards also implemented by other vendors.

You could use config mode for client-to-site IPsec connections (IPsec in tunnel mode!) without L2TP. With L2TP you will use IPsec in transport mode and L2TP is used to provide the client with IP configuration parameters, hence config mode isn't needed (and wouldn't work in IPsec transport mode)

[hanuszewski]

Thanks for all the information. This has been a great learning experience in how complex these systems can be.

I'm at a point where this is the issue:

Code: [Select]

VPN        Information        [Thu Oct 13 09:07:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: notify payload[10381]]
VPN        Error        [Thu Oct 13 09:07:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Error] [IPSEC] [Giving up on 73.81.124.10 to set up IPsec-SA due to time up]
VPN        Information        [Thu Oct 13 09:07:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: delete payload[]]
VPN        Information        [Thu Oct 13 09:08:13 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Failed 1 of 3 times to get DPD R-U-THERE-ACK from peer "73.81.124.10[14794]"]
VPN        Information        [Thu Oct 13 09:08:13 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: notify payload[10381]]
VPN        Information        [Thu Oct 13 09:08:33 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Failed 2 of 3 times to get DPD R-U-THERE-ACK from peer "73.81.124.10[14794]"]
VPN        Information        [Thu Oct 13 09:08:33 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: notify payload[10381]]
VPN        Information        [Thu Oct 13 09:08:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Failed 3 of 3 times to get DPD R-U-THERE-ACK from peer "73.81.124.10[14794]"]
VPN        Information        [Thu Oct 13 09:08:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Peer 73.81.124.10 is detected as Dead, Tearing down the connection]
But I feel like there has be be a configuration or something that is mismatched and the phone is hanging up. Nothing in the logs is standing out to me. Here is a full debug level log.
http://pastebin.com/diNraGzp

[PacketTracer]

Hi again,

what you can see from the debug log: phase 1 is finished successfully, resulting in a working ISAKMP-SA using NAT-T (your peer is behind a NAT):

Code: [Select]

[Thu Oct 13 09:07:10 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [IKE: ISAKMP-SA established for sIP2[4500]-73.81.124.10[14794] with spi:4d01b3cfd176fa77:ddc12e3700a55c22]
Then the first quick mode packet (starting phase 2) is received from the peer:

Code: [Select]

VPN        Debug        [Thu Oct 13 09:07:18 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: received IDci2:: isakmp_quick.c:1077:quick_r1recv(]
VPN        Debug        [Thu Oct 13 09:07:18 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: received IDcr2:: isakmp_quick.c:1081:quick_r1recv(]

Here is what the peer suggests to be negotiated:

Code: [Select]

VPN        Debug        [Thu Oct 13 09:07:47 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: peer's single bundle:
: ipsec_doi.c:1082:get_ph2approvalx(]
VPN        Debug        [Thu Oct 13 09:07:47 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:  (proto_id=ESP spisize=4 spi=02c697f6 spi_p=00000000 encmode=4 reqid=0:0)
: proposal.c:902:printsaproto(]
VPN        Debug        [Thu Oct 13 09:07:47 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=256 authtype=hmac-sha2-256)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=256 authtype=hmac-sha)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=256 authtype=hmac-md5)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=128 authtype=hmac-sha2-256)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=128 authtype=hmac-sha)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=128 authtype=hmac-md5)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=3DES encklen=0 authtype=hmac-sha2-256)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=3DES encklen=0 authtype=hmac-sha)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=3DES encklen=0 authtype=hmac-md5)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=DES encklen=0 authtype=hmac-sha2-256)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=DES encklen=0 authtype=hmac-sha)
: proposal.c:936:printsatrns(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=DES encklen=0 authtype=hmac-md5)
: proposal.c:936:printsatrns(]
And this is, what your DSR selects from this set:

Code: [Select]

VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: my single bundle:
: ipsec_doi.c:1085:get_ph2approvalx(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:  (proto_id=ESP spisize=4 spi=00000000 spi_p=02c697f6 encmode=4 reqid=14794:14794)
: proposal.c:902:printsaproto(]
VPN        Debug        [Thu Oct 13 09:07:48 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE:   (trns_id=RIJNDAEL encklen=256 authtype=hmac-md5)
: proposal.c:936:printsatrns(]
Looks like DSR only supports hmac-md5 instead of hmac-sha2-256 (RIJNDAEL is only another term for AES)

In addition DSR suggests an SA lifetime of 28800 seconds ...

Code: [Select]

VPN        Debug        [Thu Oct 13 09:07:49 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: type=SA Life Type, flag=0x8000, lorv=seconds
: ipsec_doi.c:2261:check_attr_ipsec(]
VPN        Debug        [Thu Oct 13 09:07:49 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: type=SA Life Duration, flag=0x8000, lorv=28800
: ipsec_doi.c:2261:check_attr_ipsec(]

... and sends the second quickmode message back to the peer:

Code: [Select]

VPN        Debug        [Thu Oct 13 09:07:51 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: sockname sIP2[4500]
: sockmisc.c:468:sendfromto(]
VPN        Debug        [Thu Oct 13 09:07:51 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: send packet from sIP2[4500]
: sockmisc.c:470:sendfromto(]
VPN        Debug        [Thu Oct 13 09:07:51 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: send packet to 73.81.124.10[14794]
: sockmisc.c:472:sendfromto(]
VPN        Debug        [Thu Oct 13 09:07:51 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: 1 times of 176 bytes message will be sent to 73.81.124.10[14794]
: sockmisc.c:632:sendfromto(]
VPN        Debug        [Thu Oct 13 09:07:51 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: resend phase2 packet 4d01b3cfd176fa77:ddc12e3700a55c22:00008ae5
: isakmp.c:1939:isakmp_ph2resend(]
VPN        Debug        [Thu Oct 13 09:07:52 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Debugging] [IPSEC] [IKE: ===
: isakmp.c:380:isakmp_handler(]
Here is why DSR deletes the SA after 60 seconds:

Code: [Select]

VPN        Information        [Thu Oct 13 09:07:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: notify payload[10381]]
VPN        Error        [Thu Oct 13 09:07:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Error] [IPSEC] [Giving up on 73.81.124.10 to set up IPsec-SA due to time up]
VPN        Information        [Thu Oct 13 09:07:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: delete payload[]]
VPN        Information        [Thu Oct 13 09:08:13 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Failed 1 of 3 times to get DPD R-U-THERE-ACK from peer "73.81.124.10[14794]"]
VPN        Information        [Thu Oct 13 09:08:13 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: notify payload[10381]]
VPN        Information        [Thu Oct 13 09:08:33 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Failed 2 of 3 times to get DPD R-U-THERE-ACK from peer "73.81.124.10[14794]"]
VPN        Information        [Thu Oct 13 09:08:33 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Sending Informational Exchange: notify payload[10381]]
VPN        Information        [Thu Oct 13 09:08:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Failed 3 of 3 times to get DPD R-U-THERE-ACK from peer "73.81.124.10[14794]"]
VPN        Information        [Thu Oct 13 09:08:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Peer 73.81.124.10 is detected as Dead, Tearing down the connection]
VPN        Information        [Thu Oct 13 09:08:53 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Purged ISAKMP-SA with spi=4d01b3cfd176fa77:ddc12e3700a55c22.]
VPN        Information        [Thu Oct 13 09:08:54 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [ISAKMP-SA deleted for sIP2[4500]-73.81.124.10[14794] with spi:4d01b3cfd176fa77:ddc12e3700a55c22]
VPN        Information        [Thu Oct 13 09:08:55 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Unable to send SMS]
VPN        Information        [Thu Oct 13 09:08:55 2016(GMT-0500)] [DSR-250] [2.11] [VPN] [Information] [IPSEC] [Unable to send Trap]

It tries DPD (dead peer detection) by sending DPD hellos every 20 seconds but never gets a DPD ack back from the peer - hence it gives up and deletes the SA.

Hence the question is why does the peer not respond to DPDs?

My idea is: The peer is behind a NAT and sends ESP via UDP/IP to your sIP2 on port 4500/UDP. This creates a UDP NAT session in the remote NAT. I guess the timeout interval for UDP based NAT sessions in the remote NAT device is shorter than 20 seconds, hence the NAT session's state is lost before the first DPD arrives which is then  not forwarded by the remote NAT device to your remote peer's private address.

As a counter measure you could reduce the detection period in your DSR's Phase 1 settings from 20 to lower values:

Dead Peer: ON
Detection Period: 20

Alternatively you could switch DPD off, but then, if NAT session is lost, the next time the peer talks to your DSR, IPsec traffic will come from another UDP port due to a newly created UDP NAT session and this could eventually provoke your DSR to stop the IKE SA either.

On the other hand I'm asking myself why after successfully finishing phase 2 nothing happens during the next 20 seconds - I'd expect the peer sending PPP frames via L2TP through the IPsec connection in order to get an IP address and start some communication afterwards. But nothing in the debug log gives a hint that this is happening

Maybe this is because you statically configured your peer to have address 172.20.20.20 (can see this as remote ID in debug log)? So I'd suggest you remove this address from the peer's IP configuration, so it will eventually request one via PPP through L2TP.

PT

[hanuszewski]

Wow, Thanks for breaking that log down. Really helped out alot. I wish the DSR-250 would log more than 1000 entries. Using debug fills that pretty quickly.

Some changes have been made.

Looks like DSR only supports hmac-md5 instead of hmac-sha2-256 (RIJNDAEL is only another term for AES)

I enabled a lot more options to help the DSR negotiate better.

I enabled Dead Peer detection and set it to 10, the lowest it can go.
NAT Keep Alive has been enabled, Frequency is also 10 seconds

On the other hand I'm asking myself why after successfully finishing phase 2 nothing happens during the next 20 seconds - I'd expect the peer sending PPP frames via L2TP through the IPsec connection in order to get an IP address and start some communication afterwards. But nothing in the debug log gives a hint that this is happening

I noticed that, it confuses the hell out of me also. It is an Android Note 5 on the Sprint network and there are "Road warriors" everywhere and I'm sure some of them use L2TP\IPSec. The phone is stock, not rooted or modified.

Maybe this is because you statically configured your peer to have address 172.20.20.20 (can see this as remote ID in debug log)? So I'd suggest you remove this address from the peer's IP configuration, so it will eventually request one via PPP through L2TP.

As for this, the phone itself doesn't have any static ip's configured. The log I posted for that test had the phone connected to an Xfinity Free wifi hotspot. That access point might do some mac address static mapping. The log that is posted at the end of this reply has the phone using the Sprint Cell network.


This is the log of the Phone while connected to the sprint cell network. http://pastebin.com/jYsRM3bP
This is the log of the Phone connected to a "DMZ" subnet attempting to vpn into the local network http://pastebin.com/kHVd5JV5
This is the log of the Phone connected to a Free Xfinity Hotspot http://pastebin.com/LMz4wFpG
Still fails to respond to the R-U-THERE message.


Making it this far makes me believe that the Comcast Gateway isn't blocking anything. Plus nothing is logged in the gateway firewall logs. Devices plugged into the DSR250 have internet access and from the Diagnostics page I can ping and perform DNS lookups without issues.

I've also included the ipv4 routing table, This is a gray area for me also.

*I have no idea what 173.12.28.232 is I dont own that IP, might be the Hotspot gateway.

[FurryNutz]

Does the DSR have a syslog feature?

[hanuszewski]

Does the DSR have a syslog feature?

Looks like it does, have to figure out how to get them.

[FurryNutz]

I know that on home class routers that support syslog, you install syslog capture software on a PC and then input an IP address into the syslog feature and enable it and the router will start sending logs to the PC. I presume maybe the DSR series maybe similar. Might help capture some additional information.

[hanuszewski]

I was able to get the syslog working, didn't really show a lot. I decided to bit the bullet and say screw the comcast router functionality. I attempted to set up the Comcast modem in Bridge mode with the DSR-250. I failed, pretty badly lol. Here are the steps I attempted:

1. Log in to the Comcast gateway and turn on bridge mode
2. Restart the Comcast gateway, aka pull the plug and let it fully reboot
3. Plug the DSR-250 into a laptop and manually configure the WAN to my comcast static IP settings, DNS 8.8.8.8, 8.8.4.4
4. Configured the DSR-250 LAN settings to 192.168.1.1, 255.255.255.0, gateway 192.168.1.1, turned LAN proxy off (not sure what that does)
5. Plugged ethernet from Comcast Gateway port 1 into WAN port of DSR-250
6. Went to diagnostic page of DSR-250 and pinged some sites and traced routed some sites
7. Plugged laptop into port 1 of DSR-250 attempted to browse internet, failed
8. released / renewed laptop ip still no internet
9. Turned on LAN Proxy, still no internet on laptop
10. Set DSR-250 max to the same as comcast gateway, No internet
11. rebooted DSR-250, no internet.
12. Gave up, got a beer, rolled everything back. Try again when I have more time.


If anyone has bridged this before, could you let me know how you did it or share some of your insights

[FurryNutz]

Any chance of getting the ISP to check this model modem to make sure you can get true bridge mode on it?
Some users say it's kind hard:
https://www.dslreports.com/forum/r29535258-Equip-Placing-DPC3939-in-bridged-mode
You might want to check out getting into a stand alone modem like a motorola/arris SB 6141 or 6180 series cable modem if you need to get the DSR working as you need it...

[hanuszewski]

Any chance of getting the ISP to check this model modem to make sure you can get true bridge mode on it?
Some users say it's kind hard:
https://www.dslreports.com/forum/r29535258-Equip-Placing-DPC3939-in-bridged-mode
You might want to check out getting into a stand alone modem like a motorola/arris SB 6141 or 6180 series cable modem if you need to get the DSR working as you need it...

Damn, why must life be so difficult.

[FurryNutz]

I hear ya. Ya, I don't care much for ISP modem/router combos. If users can avoid these, we recommend using stand alone modems with any external router. Less hassle. 

[PacketTracer]

6. Went to diagnostic page of DSR-250 and pinged some sites and traced routed some sites

... this indicates that you got it work!

With your clients behind DSR: Looks like it's just a DNS resolution problem. Guess they use your DSR not just as gateway but also as DNS resolver? Did you activate DNS relay function within your DSR? A simple check would have been, to configure a LAN client manually to use Google's DNS server.

PT

[hanuszewski]

... this indicates that you got it work!

With your clients behind DSR: Looks like it's just a DNS resolution problem. Guess they use your DSR not just as gateway but also as DNS resolver? Did you activate DNS relay function within your DSR? A simple check would have been, to configure a LAN client manually to use Google's DNS server.

PT

I knew I was pretty close. I set the dns on the lan to be 8.8.8.8, 8.8.4.4. is there a switch or something special I have to do to enable the DNS relay function?

[hanuszewski]

Another question about the user group, when doing L2TP\IPSec, should my group have both L2TP and XAuth enabled? Also should I enable extend auth edge device in the IPsec policy or the L2TP server page or both?