[SOLVED] ftp through IPSEC tunnel
-
Situation:
my ftp server on lan <–-> my pfsense firewall <---> isp router <---> internet <---> customer vpn concentrator
Between my pfsense firewall and vpn concentrator vpn ipsec is active. The network of local and remote vpn ipsec are determined by the customer and can not be changed.
Networks are:
local 10.210.112.64/29
remote 10.50.8.0/29I have configured vpn with these networks:
local 10.133.0.136/29
remote 10.50.8.0/29I have configured on the interface wan a virtual ip of "ip alias" type. The ip is 10.210.112.65.
In lan, on host 10.133.0.140, I have a fto server with ip 10.133.0.140 and this ftp server must be reached (only in active mode) by the customer on the ip 10.210.112.65.
So, I have configured port forward:
IPsec TCP * * 10.210.112.65 21 (FTP) 10.133.0.140 21 (FTP)
IPsec TCP * * 10.210.112.65 20 10.133.0.140 20and outbound:
IPsec 10.133.0.140/32 21 10.50.8.0/29 * 10.210.112.65 * NO
IPsec 10.133.0.140/32 20 10.50.8.0/29 * 10.210.112.65 * NONow, if the customer test the ftp connection, the connection is established successfully, but the dir command does not work. The customer says that the connection is on correct ip (10.210.112.65), but the response to the dir command comes from the ip 10.210.112.68, so the command hangs Why?!?
Can you help me please?
Thank you very much!
-
IPsec TCP * * 10.210.112.65 20 10.133.0.140 20is just unneeded regardless of IPsec or not… Plus, I must be missing something altogether - since I do not get the point of the port forwarding at all. It should just work without any such nonsense, at least passive FTP, that's the whole point of the VPN, no?!
EDIT: tested with OpenVPN and IPsec (site-to-site), absolutely no port-forwarding needed, active FTP works, passive works as well. Remove the alias, remove the port-forwarding, point the FTP client to the internal LAN IP of the FTP server (10.133.0.140), let it work...
-
Ok, solved!
I do not know if this is normal behavior, but it seems that in the configured situation (IPSEC: local network 10.133.0.136/29, remote network 10.50.8.0 - virtual IP "Alias type" 10.210.112.65 on which the customer connects), if I use 10.133.0.140 (fourth address of the network 10.133.0.136/29) as the address of the ftp server in the LAN, the customer sees the response from port 20 of the ftp server from the fourth ip of the network 10.210.112.64/29 (10.210.112.68), however if I use the ip 10.133.0.137 (first ip of the network 10.133.0.136/29), then responses from port 20 of the ftp server come from correct ip address 10.210.112.65 (first ip of the network 10.210.112.64/29).
Is this normal behavior? Thank you!
-
Once again, creating alias for port-forwarding to FTP server makes no sense.
-
I'm sorry, but you did not understand my configuration. In my configuration, I must create the alias, because it is part of a network decided by the customer, who otherwise would not be known by the firewall.
-
Well, once again, of course it would not be known by the firewall, since it damn makes no sense. Point the FTP client to the tunneled LAN IP of the FTP server (10.133.0.140) and the traffic will be routed just fine. Do NOT point the client to some whacky alias (10.210.112.65) which is completely outside of anything. This works out of the box, why people are reinventing the wheels?
-
In this case I'm not reinventing the wheel, but I'm adding. I agree regarding the alias, it is useless. As I clearly stated, the customer can not point to the ip of the lan (10.133.0.137), but must point to the ip of the ipsec network (10.210.112.65). That is all.
-
Yeah, and it does not work with 5 wheels either. Dude, WTF really…
10.133.0.136/29 (where the FTP server with 10.133.0.140 resides) and 10.50.8.0/29 (where the FTP client resides) can already talk to each other directly using their own LAN IPs via the IPsec tunnel established between your pfSence and the VPN concentrator. Now, you come, point the FTP client to somewhere completely else than where the FTP server listens and starting trying to NAT/portforward within (already NAT-traversed) IPsec tunnel, in addition in order to use this for active mode FTP which is just about impossible to get through NATs.
Christ almighty, go get some clue… ::) :o
As I clearly stated, the customer can not point to the ip of the lan (10.133.0.137), but must point to the ip of the ipsec network (10.210.112.65). That is all.
WTH??? They have broken keypad than cannot type the other IP, or why can't they? Maybe they could use a DNS record instead, or got a new keyboard. ::)
-
WTH??? They have broken keypad than cannot type the other IP, or why can't they? Maybe they could use a DNS record instead, or got a new keyboard.
REPEAT: the customer can not point to the ip of the lan (10.133.0.137), but must point to the ip of the ipsec network (10.210.112.65). Is a CONVENTION of the customer, it is clear now my friend?
-
Well, then by convention the customer can run their own FTP server. Or replace the censored wannabe network admin that's working there. Because they are requesting clear bullshit that won't work.
-
I'm sorry to tell you that it's working very well.
-
Yah, have fun. (Poor admin that's gonna come to maintain similar BS after you.) They could also "by convention" request that Google's DNS servers are available at 10.10.10.10 instead of 8.8.8.8 just because they don't like 8s, now you could NAT that as well. ::)
-
It's a shame that you can not understand that in some cases (like this one) conventions are necessary. Bye.
-
Nah, real shame is producing obviously BS setups that in the end cause days/weeks of time wasted by debugging issues that make no sense, or in case someone takes over your position, or just decides to finally sanitize things later on. This is not any convention, let alone necessary. Just plain brainfart. Bye as well.
-
Ok, you're done thinking about the problem of this post and you're only doing the troll. Thank you, bye.