|reply to tamz273 |
Re: Hosted VPN Solution - any ideas welcome!
Yes, it is just the ACL basically (which can be confusing once you have long ACL lines). Permitting all IP traffic on the Phase-2 ACL is the norm. Therefore should you need to permit or deny specific IP traffic, you either set it up on the access-group command, have a dedicated firewall behind the router (behind the VPN concentrator), or block by IP subnet on the VPN group.
Sounds logical, only I cant seem to get it to work. My current config only had routes in the ACL pointing a the networks behind the concentrator. So I tried to add the subnet that includes the VPN Address pool, but I still cant ping other clients connected via VPN. When I trace, I get to the concentrator and then the traffic is dropped. I tried adding a Null0 router to that /24 on the concentrator, but still now getting a Destination Host Unreachable..
EDIT: I created a loopback interface on the router with an IP from the same ip pool that is used by the clients, and I can ping it. This only works when I add a route to the crypto profile. Now my VPN client has a router for the 10.250/16 (office hosts) and then 172.21/16 (VPN Address pool + loopback addresses).
Im logged on from my phone, and still cannot ping my phones IP from my laptop for testing.. Laptop is 172.21.10.47 and phone is 172.21.10.50.. I cant ping either of those hosts from the router itself, and obviously not from the device across the router to the other device..
Any help would be appreciated!
EDIT 2: More mucking around, and I've come to find out that my iPhone doesnt like pings I fired up my mac, connected and I can ping across no prob. I need to say though, that the only way I could accomplish this was through specifying a route to the VPN Client. Without a specific route, the client didnt take default over to the router in order to reach another host on the same network..
Thanks for all the advice, and hope someone benefits from this!
Adding routes to reach machines within the same broadcast domain should not be necessary in order to have visibility of each other. If you like, you can post your configuration for people here to review.
Thats what I was thinking too.. Since its all L2.. My question though is, what IS the domain? is it a /16? where is it determined? The Address pool for the VPN is only a beginning address and end address...
From a different perspective, I would recommend virtual desktop solution instead of a simple remote IPSec VPN services. A remote IPSec VPN service is not really designed to be providing what you are aiming at since it was designed for a quick way to remote connect to data center or main office. A virtual desktop (i.e. from Citrix) on the other hand is designed to provide what you are aiming.
I think a citrix VDI solution is geared more towards giving virtual machines on a single network, not allowing your machine to join part of a virtual network... But thanks for your suggestion!
I still would like to know how the "domains" are split up.. could you help explains that part?
I think ayroba alluded to a broadcast domain, whereas any member of a VLAN should be able to ping each other within the same VLAN if all hosts are using IP addresses from the same subnet.
There's no splitting up of a broadcast domain when it crosses a VPN tunnel AFAIK. In a tunnel, you have Network A, Network B, etc etc and a route between the two as determined by the routing table.
Right, I agree.. I think he was alluding to that too. My question was "where" that defined..? Is everything in one ISAKMP profile considered one vlan? So other profiles will create other vlans?
Ive realized that if I dont specify a router for the vlan that the IP Pool range is on, I cannot ping other hosts on the same IP pool. If I add an IP to the route-filter ACL, then I can reach other hosts. This only works with I see the router in my "router details" tab in the VPN client..
With an ISAKMP profile, you reference an ACL that the assigned interface uses to forward interesting traffic through the tunnel. This ACL can specify one host or an entire subnet.
I suppose you can trick two tunnel endpoints to act as though it's bridging interesting traffic through the tunnel by using the same subnet on both ends, but I'd think that can cause issues with ARP.