No VPN Signal

[techgy]

Russell,

The modem only has a single port on the back.
We have three buildings that use AT&T as the ISP and they're all using the same modem.
I only have one building that's having problems with the VPN signal.

So before I make any changes in the modem, I'll contact the GSD this week. It's possible that there may be an issue with the firewall. Last week when were having intermittent problems with the DSL it was necessary to do a manual activation of the firewall. I'm not 100% confident that everything went as expected.

If the call to the GSD comes out unsuccessful, then I'll take a shot at setting up the modem as a bridge.

[Mikerowaved]

There's a couple of things that may be going on here:

In my area modems are just that - modems. They connect the next device (ASA firewall) to the Internet directly. The ISP will then use DHCP to assign a public IP to the firewall.

However, I understand there are devices out there that are combination modem and router. If your "modem" has more then one Ethernet jack on the back that is most certainly the case (you have a modem/router/switch). In that case your "modem" itself will take the public IP assigned by the ISP and use it's internal DHCP to assign the ASA firewall a private IP address. If the firewall is expecting a "call" from CHQ that would most certainly cause problems since the incoming packet is likely to be blocked by the "modem". If nothing else it needlessly complicates the situation.

So - bottom line. If you do have a modem/router, then yes, I would advise placing it in bridge mode or whatever it takes to disable all that extra stuff. If what you have is only a modem, then it's already doing that.

I have a DSL modem/router/WAP (no switch) in a box at one facility and tried initially to put it into bridge mode and let the ASA provide the PPPoE login credentials as well as accept the public IP address from Qwest. For some reason, that didn't work, so GSD had me configure it back to a modem/router (with the WAP disabled, of course) and it worked fine. Yes, the ASA is being assigned a private IP address from the modem, but the VPN light is green as can be and GSD had no problem accessing it to finish the configuration.

Apparently, some modem/routers will pass VPN traffic and others wont, but it IS a legitimate configuration that works in many cases.

Two points to consider...
First, if you are on DSL using a modem/router and you want to switch to bridge mode AFTER GSD has locked the ASA, you wont be able to enter the needed PPPoE credentials into the ASA's configuration. GSD will have to do this from their end.

Second, if you are on broadband cable with a modem/router that you would like to put in bridge mode, you will be changing the visible MAC address from the modem to the ASA and different providers handle this in different ways. With Comcast, just leave everything off for ~15 minutes, then they will "forget" your old MAC address allowing you to use a different one. With other providers, you must call them and have them clear the old address manually. One way around this is there's a spot in the ASA where you can manually enter the modem's MAC address thereby "cloning" it. Again, if the ASA is locked, GSD will have to do this.

Sorry, probably more info than anyone needs right now.

[jdlessley]

Actually Mikerowaved I think the information you provided is useful for others who may end up looking for a solution for similar issues.

[techgy]

The saga continues....

Our ISP has repaired a bad connection at the demark point and our Internet appears to be stable.
However, we're still having issues with the VPN light on the ASA. On Sunday, Monday and Today when I checked the ASA the VPN lamp was amber.

I'm getting a little suspicious of the DSL modem configuration. It had been configured to "Keep Alive" modem which helps to maintain activity on the line. Does anyone have any suggestions as to what mode the modem should be in?

It's a Speedstream 5100 and the ISP is AT&T.

I'm using the same modem in another building and I may compare them but as I recall I kept the default configured which would have been "Keep Alive" on both boxes. One facility with this same modem is working fine.

I'm going in circles here since we have no access to the ASA and the GSD doesn't have anyone who's familiar to the extreme with troubleshooting of the box or VPN. Our ISP won't even touch it since it's not their equipment.

My next step would be to remove the ASA completely and go back to our Router to verify that we're getting a solid DSL and that it's not dropping out.

When I arrived at our stake center a few minutes ago the VPN lamp was out. I unplugged the ASA from the modem then plugged it back in. Within a few seconds the VPN lamp was green. Go figure.....

Suggestions welcome.....

[russellhltn]

When I arrived at our stake center a few minutes ago the VPN lamp was out. I unplugged the ASA from the modem then plugged it back in. Within a few seconds the VPN lamp was green. Go figure.....

Have GSD check that the time/date on the firewall is correct.

It's not as strange as it sounds. When you unplugged/replugged the connection, you reset the TCP/IP link between the two. The function of DHCP is to lease the IP address. I'm not sure, but I think it's leased until a certain time/date rather then for a duration. If the ASA has the wrong time/date, it's going to be confused as to when it has to renew the IP lease.

[techgy]

Russell,

Thanks for the suggestion. I plan on going by the stake center again on Wednesday afternoon after work. If the VPN is out again, I'll contact the GSD and have them check the date/time.

The only other thing I've done is to configure the modem so it's configuration matches the configuration of another meetinghouse in our stake (same ISP & modem). I'm hoping that perhaps the modem configuration may had something to do with it.

[techgy]

Have GSD check that the time/date on the firewall is correct.

It's not as strange as it sounds. When you unplugged/replugged the connection, you reset the TCP/IP link between the two. The function of DHCP is to lease the IP address. I'm not sure, but I think it's leased until a certain time/date rather then for a duration. If the ASA has the wrong time/date, it's going to be confused as to when it has to renew the IP lease.

Russell,

Yesterday I stopped by the stake center and checked the ASA again. As usual, the VPN lamp was amber. So I called the GSD and asked them to check the Date/Time on the ASA. They finally had to gain access to the ASA by me using the console cable. Each time I managed to get the VPN lamp to a green condition, and the GSD tech would attempt to access the firewall, he would get kicked out or at least would lose access.

When he ultimately did gain access through the console cable and a link to my desktop we found the date/time was set to 15:49:00 on Sept 17, 2008 UTC. Inspite of our efforts to correct it he couldn't find a command to change the time. In addition we're in the PST time zone.

Another weird thing occurred several minutes later when he had reset the ASA and rescripted it, the identical date/time was displayed. It was as though the ASA isn't keeping time at all.

The GSD told me that they would be checking into sending me a replacement box and that I would then return the one we have.

[russellhltn]

we found the date/time was set to 15:49:00 on Sept 17, 2008 UTC. Inspite of our efforts to correct it he couldn't find a command to change the time. In addition we're in the PST time zone.

PST or PDT? PDT is the - 7 time zone if my math is right. So as long as this was around 8:48 AM, then that's correct. As long as the time is correct for the zone displayed, then I wouldn't worry about it. I've not looked into the details of the DHCP protocol but I wouldn't be a bit surprised but what it accounts for time zones and what not.

But given all the problems, a swap out isn't a bad idea. If that's what it takes to get GSD to buy into the fix, so be it.

[techgy]

PST or PDT? PDT is the - 7 time zone if my math is right. So as long as this was around 8:48 AM, then that's correct. As long as the time is correct for the zone displayed, then I wouldn't worry about it. I've not looked into the details of the DHCP protocol but I wouldn't be a bit surprised but what it accounts for time zones and what not.

But given all the problems, a swap out isn't a bad idea. If that's what it takes to get GSD to buy into the fix, so be it.

The time zone is PDT (pacific). However the time reported was close to our current time but it was indicating UDT, which would have been much different than our time. I'll check the internet this afternoon and see if the internet is stable after 24 hours w/o the ASA.

All I can say at this point is that the process isn't always as easy as expected.

[russellhltn]

I dug a bit deeper and it appears the lease time is for a duration, rather then a fixed time/date. So the time/date in the router shouldn't be an issue.