IPsec, L2TP, Split tunneling, PPTP and all other VPN related posts.
1 post • Page 1 of 1
We have a 3000 concentrator and is configured with a remote vpn on it. All the inside network is allowed once a user connceted to the vpn. It is totally behind of firewall. I can access it from an outside IP. But I can log into the vpn from the inside network. I can ping the public interface; but when i try to log in from the client, the server report shows no any records of my IP. Why can I log in from the Inside? thanks, =====Inside Network========VPN Concentrator=====FW=====Outside Network
Why are you trying to VPN from the inside? The purpose of VPN is to encrypt traffic between your PC on the internet towards the VPN Concentrator, once the traffic gets to your VPN Concentrator, it will be decrypted and it will go as clear text towards your internal network. So what is the purpose of trying to connect from within the inside network? The reason why it doesn work is because of routing. You are within the internal network, so the traffic will go out towards the firewall, and come back through the same firewall to connect to the VPN Concentrator public interface, which is why its not working, and if the purpose is to access internal network, then you are already inside the network which complicates things as your ip pool then needs to be routed back towards the inside. Hope that makes sense.
Jen,I know it sounds a little weird to access it from the inside network. the reason of it is that, sometimes I need to know whether the concentrator is working or not. So, what i first to do is to use my laptop beside me to log in the contrator I worked in a different gov before, and it worked this way. When you say the traffice will go to the outside and the try to go inside... Let me draw a bit more detial. =====My laptop=======Dist. Switch===Core switches(where concentrator directly connects)====Gateway switches====FW=====Outside. And my traceroute to the public interface seems not going out side, it only consists 3 hops, Dist switch, core switch and the concentrator. So, what do you think? thanks, Han
OK, makes sense. Concentrator has 2 interfaces that you would normally use: private interface which connects to your internal network, and public interface which connects to your FW. From the topology diagram, I assume that your Concentrator is behind the FW, not paralel to your FW. Need to know if Concentrator public interface is assigned public ip address OR if your FW is NATing traffic towards the Concentrator. There are a number of variables to think about, and depending on which one it is, the traffic flow will be different. Also, for normal internet traffic, how is it being routed? Not sure if this is possible within your environment, but to test if the VPN Concentrator is working or not, it is probably easier to plug a laptop to the gateway switch, and configure the laptop ip address to be in the same subnet as the VPN Concentrator public interface subnet. Another option would be if you are from internal network, to connect to the VPN Concentrator private interface ip address instead. Just trying to understand what is the common issue that you are experiencing with the VPN Concentrator? Just want to know because if you are connecting from the internal network, that probably does not simulate the real issue, so would like to know what is the common issue you are facing with this particular VPN Concentrator.
1. all the ip involved are valid IP, 199.*.*.*2. interface trafffic, when it goes outside itll hit core then gateway, then FW, then outside.3. OSPF is the routing protocol. I understand that plugging a pc to gateway is the best way, but it is in different location. what I try to do is to see why it can access from the inside and later we may need this. I am wondering when you don see any records on the reports, does it mean that the initiation didnt hit the concentrator? if it does, why does the ping hit the interface? my coworker gave me an explaination that it is due to asymetrical routing, but i am not quite sure what he exactly mean? thanks, Han