[SOLVED] ftp through IPSEC tunnel
-
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.