TCP Port 445 - Sharing Issue 1

[mantastic36]

OK. I'm not going to go into all the specifics, but here's the basics. There are three sites involved. No firewall is in place from site A to site B, it's a persistent IPSEC VPN connection, as I said before no firewall is in place that is blocking port 445 across the persistent tunnel. I would like to see shares on a windows AD domain from site A to site B and vice versa. I noticed that I can not telnet to port 445 from site A to site B and vice versa. Both sites are on the same AD domain and ad and dns replication is occurring without issues. Now let's add site C, also on the same domain, to the mix, this site can both telnet to port 445 on Ad controllers on A and B sites and guess what site A and B can telnet to port 445 on site C ad controllers. I will specify again no firewall is in place between site A and site B. Why can't I access shares on site A from site B and vice versa, if in fact the telnet proves why I can't, then why is that port only open to certain sites and not all sites if there is no present firewall in place between sites A and B?

If anyone can figure this out I'd appreciate it, because I have no idea how to fix this problem.

 

[LawnBoy]

Offhand it smells like something screwy in the VPN setups. Will you elaborate on how the 3 sites are linked together?
In order for site C to connect to site B, does it use the same VPN that is run between sites A and B? If site C has it's own VPN to site B then I'd say there's some config difference between C->B and A->B.

Stabbing in the dark...


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[mantastic36]

Hello Lawnboy

Here's more info... All links are using the same devices for tunnel termination... The one exception is that Site C which is not having any issues has an ISA firewall in front of AD controller.

A - B Link persitent VPN tunnel across two Xincom Twin-Wan devices of the same make and firmware release.

A - C Link persitent VPN tunnel across two Xincom Twin-Wan devices of the same make and firmware release.

B - C Link persitent VPN tunnel across two Xincom Twin-Wan devices of the same make and firmware release.

A Site has two AD Controllers, one using RRAS and DHCP to set static routes to other private networks on Site B and C across Twin-WAN link.

B Site has one Ad Controller, using RRAS and DHCP to set static routes to other private networks on site A and C across Twin-Wan link.

C Site has two AD Controllers, one using RRAS and DHCP to set static routes to bypass ISA firewall at this site to access other networks on site A and B by use of twin-wan tunnel link.

IN addition further troubleshooting I've tried... Ive used net monitor on site A and site B Ad controllers to see if any data gets passed from site A to B when testing telnet to port 445... I get packets on site A and site B in net monitor telling me the packets are getting from site A to site B but still fails on telnet to port 445.

Thanks,
Dave

 

[PeterHurst]

One thought - default gateways/ routes between the two networks. Does one site have a default gateway on a router other than the Twin-ax devices? If so check there are routes pointing VPN traffic the correct way.

 

[burtsbees]

Are sites A B and C on different subnets when connected to the vpn? Are the addresses on the vpn nw being NATted?

Burt

 

[mantastic36]

Hello.

All devices pointing to Twin-WAN private IP address with exception of site C, this is pointing towards ISA server as gateway, not the Xincom device. However Site A and B are the ones having issues.

As such site A 10.10.17.0/24 Gateway 10.10.17.211/24

site B 10.10.11.0/24 Gateway 10.10.11.211/24

site C 10.10.10.0/24 Gatewat 10.10.10.132/24 - Gateway is the ISA server.

NAT routing is enable on all xincom devices, not using port translation for ports 1025 - 61439

Site A can Reach Site B and vice versa as an RISC server is in place at site B that allows telnet access to see A.

More history on this issue... Site A was moved to another location, and this was working before the change, and has not worked since... Only differences is we are on a different T1 circuit and a change to internal network from 10.10.12.0/24 to 10.10.17.0/24 and a new xincom devices was put in place at site A. This new xincom device was of the same make and model and is on the same software release. Only change is from 10.10.12.0/24 to 10.10.17.0/24 private subnet.

Thanks in advance for trying to help with this one.

Thanks,
Dave