VPN and Traffic Question

[fitz]

I'm not as well versed in the world of IPSec VPN's as I would like.. and getting into a philosophical debate about the traffic and security considerations of setting up a VPN connection.

We have a vendor trying to sell us a product where we install a Cisco VPN client on a server that is used to establish a VPN connection (on demand) to their data center and then setup an FTP session over than VPN connection to download files from their data center to our server for further processing.

That's all well and good and I understand that. Where I get a little hazy is that once the VPN connection is established, isn't the traffic over that VPN connection, by definition, allowed to flow both ways (meaning, if someone on their end wanted to establish a connection to our server here hosting the VPN connection)? To me, that's a security concern because it would require me putting that VPN client into a DMZ type solution in order to insure if they had some malcontent internal employee who tried to hack (or worse, managed to break into the VPN box on our end) when the connection was active, they would then be able to use that box on our network to penetrate further into our network.

They keep telling me that the connection is one way only, but I think they are confusing the application traffic and the actual network connectivity behind it.

So, someone please enlighten me on IPSec VPN and if traffic is able to be limited in any way.

 

[X-Istence]

Off course it is both ways. How else are ACK packets and other packets to travel back to allow the connection to be fully established.

I personally use VPN on my internal network, and roaming laptops to be able to securely communicate over Wireless connections, it also allows me to then connect back from my internal network to the roaming laptop for the purpose of backups over SSH and other ports.

Yes, it is both ways.

 

[kcnychief]

You could write some rules in your firewall to allow the traffic over port 500 to only flow outbound, this way regardless of how dumb they are you are protected

 

[fitz]

that would need to be on the client side firewall though.. either that, or put a firewall behind the server being used as a client and control the traffic from the server being used as a VPN client from the rest of our LAN.

They want to put the Cisco VPN client directly on the server - this isn't site-to-site VPN, this is host-to-gateway. I'm assuming the gateway/corporate firewall would have a hard time doing filtering inside an encrypted IPSec VPN tunnel once the connection is established through that firewall..

 

[kcnychief]

Yeah, good point - maybe as an alternative if they are saying one thing (one way) and you are thinking another (two way), have them sign some sort of Contract confirming this. This way, if anything ever happens or you can prove differently, they are legally liable.

Can you have them set it up in a test environment and watch the packet traffic?

 

[fitz]

I'm at the point now where I understand a little more going on.. and either they have no clue how their product really works, or they are just treating us like crap..

I'm actually okay with the setup and the config (and the infrastructure we would put in on our end).. but I'm really not that happy with the company we are trying to business with - they have basically been ignoring our concerns and requests.. When you consider that we would basically triple their total transaction volume over the next year, it makes you wonder.

On the flip side, their sales and other non-technical support people have been really good. It's unfortunate that their tech guy is basically an a**.

 

[kcnychief]

Well, how about an alternative? IPSec is poopy anyways, why not go with SSLVPN? We also use Juniper - they have been great

 

[fitz]

not our choice of VPN.. it's the vendor's system that we are using. I'd just do away with the VPN altogether and use a SFTP connection since after the VPN is established, all they do is establish an FTP session for us to download the files.

 

[X-Istence]

I know this post was left a while ago, and I just wanted to re-visit it.

If their tech guy is the guy you are going to be working with, you should definitely not be doing any business with the company if he is unable to distinguish between one-way or two-way traffic. Especially if the traffic is over tcp/ip. Also, if he is not able to listen to your concerns and fix the problems you guys are having, it should be done with, or go to a higher up at the company. You are a paying customer, you can make demands.

Suggest FTPS (FTP over SSL), SFTP (SSH FTP) is not suggested since it requires particular software to be running on their end, an SSH server. Whereas FTPS can be accomplished on most FTP servers using TLS. Which in this case would make a lot more sense than running a VPN in, which allows uncontrolled and unmonitored access while the pipe is up (there is no good way to firewall stuff when it is being piped down a pipe. Since it is already past your border routers and whatnot)

kcnychief:

No. Setting up a rule that only allows outgoing is retarded. I was going to make fun of you in this space here for thinking that is even how it works, but instead I will hope that by me saying that it is retarded you will use Google, and look up how IPSec/VPN in general works, and figure out that even if you only allow outgoing on that port, it is a two-way tunnel, once it is established, especially since ACK, SYN, FIN, and other packets all have to travel back to the originating host somehow.

 

[fitz]

This did sort itself out..

Ended up talking to someone else over there who was a little more technical than their sales engineer who did acknowledge the fact: "Of course it's two way traffic." He also gave me a little more insight into how their product works, they do not establish an FTP session inside the VPN tunnel.. they actually do SMB file transfers over the VPN tunnel.

We ended up setting up a different VLAN and setup a firewall between that host/VLAN and the rest of our network with very limited access between that host and the rest of our corporate LAN.

Personally, I asked that we not work with the previously mentioned sales engineer.. also subtly suggested that no one else should work with him either.