VPN question

Ive got two remaining locations to get working correctly on my vpn. The tunnels are working fine. I can ping the computers using their internal address or pcanywhere into them threw the network. The computers cannot however logon to the domain (although they appear that they do because of cached info), they cannot run loggin scripts or map network drives. On trying to manually map to a network drive I get “cannot establish trust relationship”. Ive sent them new checkpoint soho 6 vpn clients thinking the boxs were defective. Removed their tunnel, gateway connections and made new ones on the main firewall. Updated the images twice on the clients. Ive even sent them both new computers that I know can logon to the network (because they were set up at corp where all the others were set-up)…but not from there. The main fw is a WG firebox III. The remote machines are dell gx270s running win2k pro and the server that administers the firewall is a 2k server. It’s a 2k network.

One of them has covad as an isp while the other has version. All the others are mostly version with two others using covad and a few cable thrown in, without a problem on any of them.

Im completely at a loss. Any suggestions?

Maybe stupid to suggest, but did you try the connection without firewalls ?

Anyway as you obviously know :p, ping is layer 3 in osi, so thats no guarantee the progs would work, so I'd start work my way up, with for.ex. try a dns resolve, an arp, a telnet , etc ...
Combine this with a networksniffer ...

That should at least give you more info ...

Hope this helps,

It sounds like you are building the tunnels directly from the client, through a firewall at the client location client to the "master" firewall, (Watchguard), at the central location rather than building a tunnel between the firewalls themselves, (something I keep intending to look at but always forget... :o ). If I'm wrong just laugh and ingnore my mental meanderings.... ;)

If I'm right then I would guess you would be providing an IP address for the remote client throught the tunnel. Questions:

1. Have you associated the DHCP subnet with the firewall under the network tab?
2. Have you told the firewall that ports 135, 137, 139 and 445 are "enabled and allowed" from the DHCP Subnet to the trusted network _and_ "enabled and allowed" from the trusted network to the DHCPed subnet or the PPTP or IPSec Groups?
3. Have you watched the Firebox monitor while you try to make the domain login type connections to see what is happening.

It sounds like you might have rules that allow Ping and PCAnywhere enabled and allowed outbound from "Any" to "Any" but, naturally, NetBios type transmissions are enabled and denied from the trusted outbound and probably from "Any" to the trusted network too.

Just some thoughts, hope it helps.

Here are a few issues that I ran into with AD and site-to-site tunnels.

1) Be sure that your VPN solution carries UDP, TCP and ICMP traffic
2) Be sure there are no port based ACLs in place
3) AD does not like NAT very much. In fact, it hates it. Are you handing out IP addresses that are part of your private IP range?

Basically, to pass AD traffic reliably, you need a wide open pipe w/o NATing. The second you start building ACLs into your tunnel and/or you try to use NAT, expect issues.

I've had similar frustrations with establishing very simple VPN connections, and my recommendation is to apply Occam's razor here: the simplest explanation is most likely to be the correct one.

In other words, my first exploration of this problem would be to determine if the traffic you're trying to send through the VPN is actually going through the VPN. Check over all the advice posted so far, but first compare your results with what happens when you try to connect with no VPN. If the results are the same, then check your IP/DNS/Gateway configuration to figure out exactly how you want traffic to flow.

If it really is going through the VPN, check those ACL's very carefully and determine if all the ports you need for AD (for DNS as well as the RPC service) are supported by your VPN software/hardware.

Good luck!

shrekkie the tunnel works fine as i said i can ping it, pcanywhere to it (tcp 5631, udp5632), i tried telnet which will only work if i enable plain text loggin, do away with NTLM and login as a local user. psexec the same thing, if i go -u <local user> then give it the password it'll give me a shell. the vpn client is also a hardware firewall which allows internet traffic originating locally for the remote which is working fine.

havn't tried a sniffer yet thats a plan.

TS the tunnel is between the soho 6 and the main fw. the client acts as a gateway for the subnet. it blocks all incoming traffic from the internet including ICMP but allows all from the subnet i set. the local networks subnet is listed in the tunnel/gateway info on the main fw otherwise i wouldn't have any communication with it.

TH13 each soho 6 is a dhcp server for its local network and each local network is assigned a seperate subnet.i dont have a problem with the few dozen others and AD and they are all NATed. just these two - /me bangs head against wall - and they are all set-up the same. encryption types match as do the keys.

brichards99 thanks for the good wishes i think ill need them. the traffic i send that does not require NTLM goes threw fine as evidenced by the telnet sessions. i can even PCA into the remote and ping my computer by name. its farging crazy i tell ya.

thank you all for your input.

TS & TH AO say i got to spread my points around so ill catch up with you. thanks again!

Tedob: Are you watching the real time monitor on the main watchguard. If you turn on all logging for the tunnel, (I forget which it is 'cos I turned it off because it was far too chatty but there's options to log GRE and a few other things to do with the tunnel), you might be able to see a problem there. You may want to baseline it with a good connection first though 'cos there is a lot of stuff that will hit the logs and most of it is in martian ;)

Since it sounds like the tunnel is ok, perhaps the problem lies in NetBios through the tunnel? It may seem like a silly question but are all the clients provided with a WINS server they can access? I know sometimes broadcasts are unable to travel through tunnels and this could be causing some problems with the clients properly locating the domain controllers.

-Maestr0

This might sound stupid but did you make sure that those clients are allowed Dial in access on the domain controller?

As far i know, AD in native mode doesnt need WINS nor broadcasting to find DCs. Just access to DNS.
You can tunnel "AD" correlated request thru VPN, but some secure channels (as written before) cant be NATed because they carry source ip address inside the cripto payload (I could nver establish a complete conversation thru NAT).