As subject really. I have a network behind an ASA 5505 and we need to monitor web usage. We have an agreement with Webroot and their Web Security SaaS. Question is, how can I force all outbound traffic to go out via the Webroot proxy servers?
We have 2 sites that will be linked by a IPSEC VPN between 2 Cisco ASAs:
Site 1 8Mb ADSL Connection Cisco ASA 505
Site 2 2Mb SDSL Connection Cisco ASA 505
Basically, both sites need access to a service at the end of another IPSEC VPN, Site 3, which I plan to terminate at Site 2. This is due to the way the service is sold - it's billed per gateway. So if both Site 1 and Site 2 had their own VPN connection to Site 3, it would cost us twice as much... Anyway, my idea is to have all traffic from Site 1 destined for Site 3 to go via the VPN between Site 1 and Site 2. The end result being all traffic that hits Site 3 has come via Site 2.
I understand this is known as hairpinning but I'm struggling to find a great deal of information on how this is setup. So, firstly, can anyone confirm that what I'm trying to achieve is possible and, secondly, can anyone point me in the direction of an example of such a configuration?
Many Thanks.
I have a situation where I require an IPSEC tunnel between two sites. Site 2 is a small branch office with basic (ADSL) connectivity and Site 1 is the "main" office with SDSL and ADSL for redundancy should the SDSL fail. From Site 1, all traffic bound for the 172.0.0.0 network will then be sent down another IPSEC tunnel to a supplier's Remote Server. See this page for the basic premise (this is a rough idea and things can be moved about etc...)
I am considering specifying Cisco ASA devices as the firewalls for both sites for all connections. Would it be possible to employ something like HSRC to provide a backup at Site 1 should the SDSL go down? I suppose the key aims here are that Site 2 can somehow failover to initiate a VPN to the ASA behind the ADSL at Site 1. I will have a 21 subnet mask on all internet connections so can play with Class C routing if need be...
If I'm barking up the wrong tree with HSRC, is there another way I can acheive this without massive expenditure on Barracuda routers et al?
Many Thanks.
Strange problem....
I have a W2003 DC also running file and print sharing. Since a reboot a couple of days ago, legacy devices that used mapped printers to this server are no longer able to connect. These legacy devices all connect via IP - \192.0.0.2\printersharename.
On closer inspection, I notice that if browse to \192.0.0.2 I can see all shares but if I double click any of the printers I get "Operation could not be completed. Either the printer name was typed incorrectly, or the specified printer has lost connection to the network." However, if I browse to the netbios or FQDN of the same server, I am able to connect to the printers without any problem. It may also be relevent that I can access the shared folders using any method without error.
The behaviour described above is evident whether I try connecting from another LAN member or from the server in question itself.
Unfortunatley the legacy devices that connect via IP cannot be changed to use the netbios or FQDN.
Any ideas?
I have two contracters who need access to our SQL LOB application. They will be connecting via VPN to a router that authenitcates via RADIUS on the DC. Now, the two servers in question are DCs. The users created are members of on Security Group - VPN Users. The only security rights attached to this group is dialin access.
On paper, this should be a straightforward. The fly in the ointment is that maybe 75% of the share permissions on these servers include Full Access for Authenticated Users. Don't ask why and no there's no chance to correct this at the moment.
SQL lives on DC2 but the ODBC settings on the client software negate any need for domain authentication. So, all I need is to stop these VPN users from browsing the network for shares and accessing them.
I have tried setting "Deny access from network" in the DC Security Policy but this seemingly hasn't helped.
For info: Both servers are W2003 SP2 Standard. The clients will be using XP/Vista.
TIA