L2TP VPN not connecting

Question

Level 4

2,740 points

L2TP VPN not connecting

I have been working on getting L2TP VPN connections to work for quite a while with no success. PTPP connections do work, however, with no difficulty. I had a previous thread running on this that went into the archived state and I'm starting afresh, carrying over a conversation from an unrelated thread to keep this more on-track.

The vpnd log reads this when trying to establish a L2TP connection:

Sat Nov 7 09:57:50 2009 : Directory Services Authentication plugin initialized
Sat Nov 7 09:57:50 2009 : Directory Services Authorization plugin initialized
Sat Nov 7 09:57:50 2009 : L2TP incoming call in progress from 'xx.xx.xx.xx'...
Sat Nov 7 09:57:50 2009 : L2TP received SCCRQ
Sat Nov 7 09:57:50 2009 : L2TP sent SCCRP
2009-11-07 09:57:52 PST Incoming call... Address given to client = 10.0.0.60
Sat Nov 7 09:57:52 2009 : Directory Services Authentication plugin initialized
Sat Nov 7 09:57:52 2009 : Directory Services Authorization plugin initialized
Sat Nov 7 09:57:52 2009 : L2TP incoming call in progress from 'xx.xx.xx.xx'...
Sat Nov 7 09:57:52 2009 : L2TP received SCCRQ
Sat Nov 7 09:57:52 2009 : L2TP sent SCCRP
2009-11-07 09:57:56 PST Incoming call... Address given to client = 10.0.0.61
Sat Nov 7 09:57:56 2009 : Directory Services Authentication plugin initialized
Sat Nov 7 09:57:56 2009 : Directory Services Authorization plugin initialized
Sat Nov 7 09:57:56 2009 : L2TP incoming call in progress from 'xx.xx.xx.xx'...
Sat Nov 7 09:57:56 2009 : L2TP received SCCRQ
Sat Nov 7 09:57:56 2009 : L2TP sent SCCRP
2009-11-07 09:58:04 PST Incoming call... Address given to client = 10.0.0.62
Sat Nov 7 09:58:04 2009 : Directory Services Authentication plugin initialized
Sat Nov 7 09:58:04 2009 : Directory Services Authorization plugin initialized
Sat Nov 7 09:58:04 2009 : L2TP incoming call in progress from 'xx.xx.xx.xx'...
Sat Nov 7 09:58:04 2009 : L2TP received SCCRQ
Sat Nov 7 09:58:04 2009 : L2TP sent SCCRP
2009-11-07 09:58:10 PST --> Client with address = 10.0.0.59 has hungup
2009-11-07 09:58:12 PST --> Client with address = 10.0.0.60 has hungup
2009-11-07 09:58:16 PST --> Client with address = 10.0.0.61 has hungup
2009-11-07 09:58:24 PST --> Client with address = 10.0.0.62 has hungup

All the appropriate firewall ports are open as near as I can tell after poring over them and the instructions in Network Services Admin.

-Doug

Mac Pro (2X 3Ghz dual core); MacBook 2GHz C2D; G4 MDD Dual 867, Mac OS X (10.6.1), 20" Cinema Display; 30GB iPod Photo; iPhone; Airport Exteme

Posted on Nov 7, 2009 10:04 AM

Reply

Answer 1

Nov 7, 2009 11:44 AM in response to Douggo

So you are setting up the tunnel (paritally) but a response packet from the client to finalize the tunnel to use is being munged or dropped/blocked, and so the session fails.

First lets look at a 'working' L2tp/IPSEC connection from 10.5. Here is mine.

Sun Jul 5 16:16:36 2009 : L2TP incoming call in progress from '12.119.255.255'...
Sun Jul 5 16:16:36 2009 : L2TP received SCCRQ
Sun Jul 5 16:16:36 2009 : L2TP sent SCCRP
Sun Jul 5 16:16:36 2009 : L2TP received SCCCN
Sun Jul 5 16:16:36 2009 : L2TP received ICRQ
Sun Jul 5 16:16:36 2009 : L2TP sent ICRP
Sun Jul 5 16:16:36 2009 : L2TP received ICCN
Sun Jul 5 16:16:36 2009 : L2TP connection established.
Sun Jul 5 16:16:36 2009 : using link 0
Sun Jul 5 16:16:36 2009 : Using interface ppp0
Sun Jul 5 16:16:36 2009 : Connect: ppp0 <--> socket\[34:18]
Sun Jul 5 16:16:36 2009 : sent \[LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x308870df> <pcomp> <accomp>]
Sun Jul 5 16:16:36 2009 : rcvd \[LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe137092c> <pcomp> <accomp>]
Sun Jul 5 16:16:36 2009 : lcp_reqci: returning CONFACK.
Sun Jul 5 16:16:36 2009 : sent \[LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xe137092c> <pcomp> <accomp>]
Sun Jul 5 16:16:36 2009 : rcvd \[LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x308870df> <pcomp> <accomp>]
Sun Jul 5 16:16:36 2009 : sent \[LCP EchoReq id=0x0 magic=0x308870df]
Sun Jul 5 16:16:36 2009 : sent \[CHAP Challenge id=0x8b <7005cb4dc4b1bdcfe452fa7612fe23af>, name = "rmscomputersystems.com"]
Sun Jul 5 16:16:36 2009 : rcvd \[LCP EchoReq id=0x0 magic=0xe137092c]
Sun Jul 5 16:16:36 2009 : sent \[LCP EchoRep id=0x0 magic=0x308870df]
Sun Jul 5 16:16:36 2009 : rcvd \[LCP EchoRep id=0x0 magic=0xe137092c]
Sun Jul 5 16:16:36 2009 : rcvd \[CHAP Response id=0x8b <e9d8602dbdf8e54ddead506ab56dc5370000000000000000dc5471041999389180638d93a1250a af52896c5d52b8f
87200>, name = "userid"]
Sun Jul 5 16:16:36 2009 : DSAuth plugin: Could not retrieve key agent account information.
Sun Jul 5 16:16:36 2009 : sent \[CHAP Success id=0x8b "S=A17170CF2FCD1362718FC891EBD4C52D8E07B5FD M=Access granted"]
Sun Jul 5 16:16:36 2009 : CHAP peer authentication succeeded for userID
Sun Jul 5 16:16:37 2009 : DSAccessControl plugin: User 'userID' authorized for access

So the steps you completed were:
L2TP SCCRQ (start control connection request); The Client asks the server to use a specific tunnel #.

Next is L2TP SCCRP (start control connection reply); The server, across that agreed new tunnel, tells the client what ACTUAL tunnel to use.

But the next message should be from the client ot agree to the new tunnel #, L2TP SCCCN (tunnel establishment confirm).

So the server is either not getting the response, which should be the 'fault' of the firewall/NAT or the Server is not actually able to pass the SCCRP properly, which again is either NAT's fault or the Firewall.

The next few conversations would have established the session info to be secured.

L2TP ICRQ (incoming call request)
L2TP ICRP (incoming call reply)
L2TP ICCN (incoming call connected)

Alright the L2TP lesson is over, now we need to fix 😉 You are going to have to recheck that firewall. We cannot assume it is still setup properly for L2TP, so we need to assume it is NOT setup properly. You need the following forwarded to the VPN server's ip;

Port 500 UDP
Port 4500 UDP
Port 1701 UDP
and
protocol 50 (ESP) <-- this is a protocol, not TCP or UDP port 50.
For grins and giggles, add protocol 51 (AH) (Authentication Header) to this list of forwarded to the VPN service.

Let's see what that does.

Reply

Answer 2

Douggo Author

Level 4

2,740 points

Nov 7, 2009 12:43 PM in response to Peter Scordamaglia

Hi Peter,

Port 500 UDP <- Yep, had it enabled
Port 4500 UDP <- Yep, had it enabled
Port 1701 UDP <- Yep, had it enabled
protocol 50 (ESP) <- Yep, had it enabled

Hence what makes this so vexing: the required ports are open - some of which are shared with PTPP - and still no joy.

<div class="jive-quote">For grins and giggles, add protocol 51 (AH) (Authentication Header) to this list of forwarded to the VPN service.

Uh, I don't see that one listed.. ?? Nor do I see a way of adding a protocol.

-Doug

Reply

Answer 3

Nov 7, 2009 12:59 PM in response to Douggo

OK We need to see your ipfw list. You are using the Mac Firewall? Send your ipfw list like this `sudo ipfw -aSt list`

Reply

Answer 4

Douggo Author

Level 4

2,740 points

Nov 7, 2009 1:08 PM in response to Peter Scordamaglia

Okay, the ifpw list is:

00001 416 57510 Sat Nov 7 13:00:44 2009 set 0 allow udp from any 626 to any dst-port 626
00010 65111 10462733 Sat Nov 7 13:00:51 2009 set 0 divert 8668 ip from any to any via en0
01000 4378 1044949 Sat Nov 7 13:00:48 2009 set 0 allow ip from any to any via lo0
12300 129626 20309681 Sat Nov 7 13:00:51 2009 set 0 allow tcp from any to any established
12301 64 4096 Sat Nov 7 13:00:44 2009 set 0 allow tcp from any to any out
12302 1 64 Sat Nov 7 13:00:44 2009 set 0 allow tcp from any to any dst-port 22
12302 0 0 set 0 allow udp from any to any dst-port 22
12303 623 81651 Sat Nov 7 13:00:45 2009 set 0 allow udp from any to any out keep-state
12304 0 0 set 0 allow tcp from any to any dst-port 53 out keep-state
12304 0 0 set 0 allow udp from any to any dst-port 53 out keep-state
12305 0 0 set 0 allow udp from any to any in frag
12306 78 4992 Sat Nov 7 13:00:44 2009 set 0 allow tcp from any to any dst-port 311
12307 0 0 set 0 allow tcp from any to any dst-port 625
12308 0 0 set 0 allow icmp from any to any icmptypes 8
12309 0 0 set 0 allow icmp from any to any icmptypes 0
12310 115 3328 Sat Nov 7 13:00:10 2009 set 0 allow igmp from any to any
12311 0 0 set 0 allow esp from any to any
12312 62791 11224534 Sat Nov 7 13:00:51 2009 set 0 allow gre from any to any
12313 0 0 set 0 allow udp from any to any dst-port 4500
12314 0 0 set 0 allow udp from any to any dst-port 500
12315 0 0 set 0 allow udp from any to any dst-port 1701
12316 0 0 set 0 allow tcp from any to any dst-port 1723
12317 0 0 set 0 allow tcp from any to any dst-port 548
12318 0 0 set 0 allow tcp from any to any dst-port 497
12318 0 0 set 0 allow udp from any to any dst-port 497
12319 0 0 set 0 allow tcp from any to any dst-port 687
12320 0 0 set 0 allow tcp from any to any dst-port 20-21
12321 0 0 set 0 allow tcp from any to any dst-port 49152-65535 in keep-state
12322 0 0 set 0 allow tcp from any to any dst-port 80
12323 0 0 set 0 allow tcp from any to any dst-port 389
12324 0 0 set 0 allow tcp from any to any dst-port 22024
12325 0 0 set 0 allow tcp from any to any dst-port 113
12326 0 0 set 0 allow tcp from any to any dst-port 3283,5900
12326 0 0 set 0 allow udp from any to any dst-port 3283,5900
12327 0 0 set 0 allow tcp from any to any dst-port 3306
12328 441 54956 Sat Nov 7 13:00:34 2009 set 0 allow udp from any to any in keep-state
12329 0 0 set 0 allow tcp from any to any dst-port 8080
12330 0 0 set 0 allow ip from 10.0.0.0/8 to any via en1 keep-state
12331 0 0 set 0 allow udp from any 68 to any dst-port 67 via en1
63200 0 0 set 0 deny log icmp from any to any in icmptypes 0,8
63300 0 0 set 0 deny log igmp from any to any in
65000 0 0 set 0 deny log tcp from any to any in setup
65535 245 28640 Sat Nov 7 12:38:06 2009 set 31 allow ip from any to any

-Doug
<sorry I can't fix the formatting on that to ease the readability>

Reply

Answer 5

Nov 7, 2009 2:34 PM in response to Douggo

Question: Does L2TP work for internal clients?

The answer to that will move me in one of two directions.

Reply

Answer 6

Douggo Author

Level 4

2,740 points

Nov 7, 2009 2:45 PM in response to Peter Scordamaglia

Hmm.. given that the routing for the L2TP connections I have configured is through the external public IP of the server.. But no, trying to connect via VPN when inside the network (IP address in the 10.0.0/8 range) fails as well.

On a lark, I created another L2TP VPN config (using the server's internal IP address) to try piggy-backing onto the established PTPP connection I have and it fails as well:

2009-11-07 14:40:10 PST Incoming call... Address given to client = 10.0.0.57
Sat Nov 7 14:40:10 2009 : Directory Services Authentication plugin initialized
Sat Nov 7 14:40:10 2009 : Directory Services Authorization plugin initialized
Sat Nov 7 14:40:10 2009 : L2TP incoming call in progress from '10.0.0.65'...
Sat Nov 7 14:40:10 2009 : L2TP received SCCRQ
Sat Nov 7 14:40:10 2009 : L2TP sent SCCRP
2009-11-07 14:40:12 PST Incoming call... Address given to client = 10.0.0.58
<etc...>

-Doug

Reply

Answer 7

Nov 7, 2009 4:20 PM in response to Douggo

I am confused. VPN has no direct routing built into it. Even if you set the network routing definition wrong for your network, the connection to the VPN service would still work.

I think we need to go back to a simpler set of questions... I was pulling on a thread I thought would get to the answer but there may be others that are more important.

Q1: How many NIC's in the server?
Q2: Is this the Mac Pro you are 'advertising' in your tagline?
Q3: Are you 'attached' to using 10.0.0.0/8 for DNS/DHCP or can it change?
Q4: Is your external IP static, pseudo-static, or fairly dynamic?
Q5: Is this 10.5 or 10.6 server?
Q6: Was this a fresh install of above or upgrade (ever).

Apologies for the apparent back-pedaling but I think that this will put us on much better footing.

Reply

Answer 8

Douggo Author

Level 4

2,740 points

Nov 7, 2009 5:08 PM in response to Peter Scordamaglia

I am confused. VPN has no direct routing built into it.

My bad for confusing the issue. My configuration for the VPN client connection (both PTPP and L2TP) point to the public IP address of the server. So when I'm at work, with an IP of 10.0.0.137, my VPN setup on the client still hits 75.xx.xx.xx to establish a connection.

VPN setup on the server uses two small blocks of addresses in the 10.0.0/8 range, one block for each protocol, and neither of the blocks have overlapping ranges and no other devices on the LAN are using them either.

Q1: How many NIC's in the server?

Two; one connected to the modem and the second to a switch tied to our internal network.

Q2: Is this the Mac Pro you are 'advertising' in your tagline?

No, the server in question is an XServe, Dual-G5. (The Mac Pro and MacBook in my profile are my personal, home machines.)

Q3: Are you 'attached' to using 10.0.0.0/8 for DNS/DHCP or can it change?

Yes, we're tied to 10.0.0/8 internally, all fixed-IP's, no DHCP, no DNS (as of yet 😉 ). We really need to run static internal IPs because of the RIP system we run is not tolerant of having addresses floating because of DHCP. The RIP is running on a Win2K Server box with the PCMacLAN client and modified Hosts file to keep it talking to our other XServe which is the primary file server - SFM won't cut it talking to 10.5 Server.

DHCP is enabled on the XServe in question, but not advertising our 10.0.0/8 range.

Q4: Is your external IP static, pseudo-static, or fairly dynamic?

Static, as assigned to us by our ISP (Comcast, BusinessClass service). Actually, I just got a block of five static IPs that I'll be migrating to in the coming weeks. Right now though, one single static IP used only for the NIC port on the XServe in question.

Q5: Is this 10.5 or 10.6 server?

10.5.8, all updated.

Q6: Was this a fresh install of above or upgrade (ever).

Started off running as an upgrade, but later wiped and clean-installed.

Apologies for the apparent back-pedaling but I think that this will put us on much better footing.

Apology not needed! I appreciate the patience and help!! I know how it is trying to figure something out without the background info needed to flesh out the picture.

Thanks again,

-Doug

Reply

Answer 9

Douggo Author

Level 4

2,740 points

Nov 7, 2009 11:47 PM in response to Peter Scordamaglia

Some further info, from my system.log during the connection attempt:

Nov 7 23:36:35 Mac-Pro pppd[83046]: pppd 2.4.2 (Apple version 412) started by douggroesbeck, uid 501
Nov 7 23:36:35 Mac-Pro pppd[83046]: L2TP connecting to server 'xx.xx.xx.xx' (xx.xx.xx.xx)...
Nov 7 23:36:35 Mac-Pro pppd[83046]: IPSec connection started
Nov 7 23:36:35 Mac-Pro racoon[88]: Connecting.
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: transmit success. (Initiator, Main-Mode message 1).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: receive success. (Initiator, Main-Mode message 2).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: transmit success. (Initiator, Main-Mode message 3).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: receive success. (Initiator, Main-Mode message 4).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: transmit success. (Initiator, Main-Mode message 5).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKEv1 Phase1 AUTH: success. (Initiator, Main-Mode Message 6).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: receive success. (Initiator, Main-Mode message 6).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKEv1 Phase1 Initiator: success. (Initiator, Main-Mode).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKE Packet: transmit success. (Information message).
Nov 7 23:36:35 Mac-Pro racoon[88]: IKEv1 Information-Notice: transmit success. (ISAKMP-SA).
Nov 7 23:36:36 Mac-Pro racoon[88]: IKE Packet: transmit success. (Initiator, Quick-Mode message 1).
Nov 7 23:36:36 Mac-Pro racoon[88]: IKE Packet: receive success. (Initiator, Quick-Mode message 2).
Nov 7 23:36:36 Mac-Pro racoon[88]: IKE Packet: transmit success. (Initiator, Quick-Mode message 3).
Nov 7 23:36:36 Mac-Pro racoon[88]: IKEv1 Phase2 Initiator: success. (Initiator, Quick-Mode).
Nov 7 23:36:36 Mac-Pro racoon[88]: Connected.
Nov 7 23:36:36 Mac-Pro pppd[83046]: IPSec connection established
Nov 7 23:36:56 Mac-Pro pppd[83046]: L2TP cannot connect to the server
Nov 7 23:36:56 Mac-Pro configd[14]: SCNCController: Disconnecting. (Connection tried to negotiate for, 22 seconds).
Nov 7 23:36:56 Mac-Pro racoon[88]: IKE Packet: transmit success. (Information message).
Nov 7 23:36:56 Mac-Pro racoon[88]: IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA).
Nov 7 23:36:56 Mac-Pro racoon[88]: IKE Packet: transmit success. (Information message).
Nov 7 23:36:56 Mac-Pro racoon[88]: IKEv1 Information-Notice: transmit success. (Delete ISAKMP-SA).
Nov 7 23:36:56 Mac-Pro racoon[88]: Disconnecting. (Connection was up for, 20.019174 seconds).

My ppp.log basically echoes what the vpnd log is showing on the server.

HTH,

-Doug

Reply

Answer 10

Nov 8, 2009 8:28 AM in response to Douggo

OK can you do the following: unplug your connection to the internet (Modem off, whatever it takes to protect you from the next step) and then shut off NAT and the Firewall, then try to connect to PPTP and L2TP via an internal client. It HAS to be that firewall...

I don't see anything extremely wrong with your firewall (except for a repeated line 12326 which is not be allowed but that is it). It possibly is the 'order' of the lines, which is important, lower numbered lines would be triggered more often. If I had another NIC I would try out your firewall config to help out. Also another choice would be to add protocol 51 'by hand', like this

`ipfw add 012332 allow ah from any to any`

Reply

Answer 11

Douggo Author

Level 4

2,740 points

Nov 8, 2009 11:01 AM in response to Peter Scordamaglia

OK can you do the following:...

That will have to be tomorrow when I am at work again. Not going to make a second trip up there this weekend.. But I will give that a try and let you know what happens.

another choice would be to add protocol 51 'by hand'

Tried that and it generated a different group of log entries:

Nov 8 10:49:05 xserve1 vpnd[58]: Incoming call... Address given to client = 10.0.0.55
Nov 8 10:49:05 xserve1 com.apple.ppp.l2tp[58]: 2009-11-08 10:49:05 PST Incoming call... Address given to client = 10.0.0.55
Nov 8 10:49:05 xserve1 com.apple.KerberosAutoConfig[32044]: Couldn't find KerberosClient config record
Nov 8 10:49:05 xserve1 /usr/sbin/serialnumberd[112]: Responding to network change notification.
Nov 8 10:49:05: --- last message repeated 1 time ---
Nov 8 10:49:05 xserve1 pppd[32045]: pppd 2.4.2 (Apple version 314.0.2) started by _mdnsresponder, uid 0
Nov 8 10:49:05 xserve1 /usr/sbin/serialnumberd[112]: Responding to network change notification.
Nov 8 10:49:05: --- last message repeated 1 time ---
Nov 8 10:49:05 xserve1 pppd[32045]: L2TP incoming call in progress from 'xx.xx.xx.xx'...
Nov 8 10:49:05 xserve1 vpnd[58]: Incoming call... Address given to client = 10.0.0.56
Nov 8 10:49:05 xserve1 com.apple.ppp.l2tp[58]: 2009-11-08 10:49:05 PST Incoming call... Address given to client = 10.0.0.56
Nov 8 10:49:05 xserve1 /usr/sbin/serialnumberd[112]: Responding to network change notification.
Nov 8 10:49:05: --- last message repeated 1 time ---
Nov 8 10:49:05 xserve1 pppd[32046]: pppd 2.4.2 (Apple version 314.0.2) started by _mdnsresponder, uid 0
Nov 8 10:49:05 xserve1 /usr/sbin/serialnumberd[112]: Responding to network change notification.
Nov 8 10:49:05: --- last message repeated 1 time ---
Nov 8 10:49:05 xserve1 pppd[32046]: L2TP incoming call in progress from 'xx.xx.xx.xx'...

-Doug

Reply

Answer 12

Nov 8, 2009 12:50 PM in response to Douggo

hmm, can you get that from the vpnd.log? Some of those are expected as the routing tables are changing when a connection is starting up.

For your edification. the reason I asked you to run sudo ipfw -det list` (or similar)

so that shows (via the -t option) the number of packets that matched a specific rule. There aren't many that are matching your rules.

1 416 57510 set 0 allow udp from any 626 to any dst-port 626
10 65111 10462733 set 0 divert 8668 ip from any to any via en0
1000 4378 1044949 set 0 allow ip from any to any via lo0
12300 129626 20309681 set 0 allow tcp from any to any established
12301 64 4096 set 0 allow tcp from any to any out
12302 1 64 set 0 allow tcp from any to any dst-port 22
12303 623 81651 set 0 allow udp from any to any out keep-state
12306 78 4992 set 0 allow tcp from any to any dst-port 311
12310 115 3328 set 0 allow igmp from any to any
12312 62791 11224534 set 0 allow gre from any to any
12328 441 54956 set 0 allow udp from any to any in keep-state
65535 245 28640 set31 allow ip from any to any

So GRE is matching (that is for PPTP or IPSec), but the other ports are NOT matching so they are being 'caught into other rules' this is the reason for the above suggestion. I am expecting that this will work and that the firewall will have to be rebuilt.

Good Luck.
Peter

Reply

Answer 13

Douggo Author

Level 4

2,740 points

Nov 8, 2009 1:28 PM in response to Peter Scordamaglia

Yes, the entries in my previous post were taken from the vpnd.log immediately after trying to connect via L2TP with the AH port enabled as you requested. The result on the client side was the same as before - "The server is not responding.."

I can get you the results of 'ipfw -det list' if that would be helpful. I would rather email it than post here, if that's acceptable. (Your business website is in your profile - email link there..)

I am expecting that this will work and that the firewall will have to be rebuilt.

I suspect that you meant "this will NOT work.." Rebuild the firewall? Sounds like fun! Not. 😉

-Doug

Reply

Answer 14

Nov 8, 2009 4:10 PM in response to Douggo

Contacting me offline would be fine.

The comment about working was in reference to that I am thinking that by disabling the firewall the connectivity will work. For the firewall, it will reset fine and be built back up easily enough. I find that most will end up locking a site down too far (not exactly a bad thing) and then we can tone it down and get it into the Goldilocks zone. A tool I use to watch my firewall is waterroof http://www.hanynet.com/waterroof/.

Peter

Reply

Answer 15

Douggo Author

Level 4

2,740 points

Nov 8, 2009 8:08 PM in response to Peter Scordamaglia

I will fire that off this evening and check VPN on the inside of the network tomorrow.

-Doug

Reply