Assistance to securely forward a URL from the internet to a single port to multiple PCs on the LAN network
-
Hello Everyone. I need help and quite possibly a better understanding of why PFsense gives me an overlap error.
My client has a billing software on 3 PCs behind the PFsense firewall on the LAN network. This software must go through Port 22 to a specific address on the internet, sshftp.zirmed.com, to submit billing documents. I don't know why they must use Port 22 as I see that as a security risk. The way I set about to do this is I created an alias with the URL stated above, then created a Port Forward under NAT where I set the alias as the Source, the Redirect as a Single host on my LAN network, set the Source, Destination, and Redirect Ports as SSH, Interface as WAN, iPv4, and Protocol as TCP. Nat Reflection is enabled with NAT + Proxy.
Am I doing this correctly? If I try to copy the rule and set another Redirect IP, I get the Overlap error and cannot save the copied rule. Is there a better way to approach this? Please advise, thanks.
Also, am I safe opening Port 22 if I have SSH disabled on the PC on the LAN network?
Thanks for any assistance.
-
@tomsawyer2k5 said in Assistance to securely forward a URL from the internet to a single port to multiple PCs on the LAN network:
This software must go through Port 22 to a specific address on the internet
Why would you setup a port forward? Port 22 is ssh, which would be secure communication to something..
This should work out of the box with the default lan rule that allows clients to talk to anything on any port..
Port forwards are for when something on the internet wants to make a connection to your service.. Like you were running a webserver or etc.. Submitting documents wouldn't be that.. sshftp as their name would most likely mean they are uploading documents via sftp, which is a flavor of ftp just over secure ssh port 22..
Were you reading some of their documentation, and they mentioned that 22 to that fqdn needs to be open? That is because many corp network would block that traffic outbound from their network, or only allow proxy access to the internet. So the corp that uses their service would need to make sure machines being used to submit these documents to them can go outbound to that fqdn (Ip) on port 22.
Unless you have modified pfsense, this would work right out of the box.
-
@johnpoz Thank you for your reply, and bringing me back to sanity. I thought this was the case until the billing person ran into the error in the pic:
The customer support agent of the software requested me to forward the port, even though I raised concerns about exposing port 22 to the internet. Which is why I went about in the method described in the opening post to prevent others from taking advantage of the open Port 22.
I haven't done any special configurations to the PFsense router other than the usual port forwards for required applications.
At this point, unless Windows Firewall is doing something wonky behind the scenes, then there must be something else going on that is preventing this from working. Though I have this itchy feeling that somehow this is going to be solved on the customer service end and it will have nothing to do with PFsense configuration because that's what usually happens -_-
-
@tomsawyer2k5 yeah it has zero to do with pfsense.. Unless you blocking outbound access on 22, or to that IP..
Here is what I get when I try and talk to that fqdn..
I would use say putty and try and connect, I get a login prompt..
If you don't get a login prompt that your having a connectivity problem, ie maybe your blocking outbound? They are blocking or just can't get there.. I would then try to login with the creds you have..
Yeah their support is clueless it seems - no you would not setup a "port forward" on your end to talk to them.. Do you setup port forwards to talk to www.google.com - same principle!! just different port..
If you get prompted for username - then your connecting, and either you don't have valid creds, or they have an issue ... But a prompt for login validates that your talking to their server on 22, and you have exchanged the keys and agreed upon proper cipher etc.. that makes the ssh connection secure..
edit:
So vs using putty I used just cmd line ssh so I could get a better idea of what they are using, etc. And they are using a deprecated host key ssh-rsa is old, etc..Unable to negotiate with 69.2.197.40 port 22: no matching host key type found. Their offer: ssh-rsa
I had to allow for that and then I could connect.. Putty doesn't seem to be as strict current openssh client
$ ssh -v -oHostKeyAlgorithms=+ssh-rsa root@sshftp.zirmed.com OpenSSH_9.7p1, OpenSSL 3.0.13 30 Jan 2024 debug1: Connecting to sshftp.zirmed.com [69.2.197.40] port 22. debug1: Connection established. debug1: Local version string SSH-2.0-OpenSSH_9.7 debug1: Remote protocol version 2.0, remote software version 7.9.0.0_openssh Globalscape debug1: compat_banner: no match: 7.9.0.0_openssh Globalscape debug1: Authenticating to sshftp.zirmed.com:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group-exchange-sha256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_GROUP received debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: SSH2_MSG_KEX_DH_GEX_REPLY received debug1: Server host key: ssh-rsa SHA256:oZomcIzaNx+A43aULWENk1VplP1DGIR8p2cYqpnaY+4 The authenticity of host 'sshftp.zirmed.com (69.2.197.40)' can't be established. RSA key fingerprint is SHA256:oZomcIzaNx+A43aULWENk1VplP1DGIR8p2cYqpnaY+4. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'sshftp.zirmed.com' (RSA) to the list of known hosts. debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 4294967296 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: password,publickey,keyboard-interactive debug1: Authentications that can continue: password,publickey,keyboard-interactive debug1: Next authentication method: keyboard-interactive (root@sshftp.zirmed.com) Enter password:You can see they are running "remote software version 7.9.0.0_openssh Globalscape"
and got through all the key exchanges and selections for encryption, etc. And asking me to auth.. -
@johnpoz Thanks again for the assistance. I let their customer service know that there is no need to forward a port to communicate outwards. To prove this I ran a command in Powershell called "Test-NetConnection sshftp.zirmed.com -Port 22" and I got the TcpTestSucceeded : True . Then I sent them the screenshot of the PowerShell window. Now they're saying it might be a "configuration issue" on that specific workstation
Sometimes these customer service folks 
So at this point I can leave the wonderful, powerful PFsense device alone and actually solve the problem from where we should've started in the first place: the software itself.
PS: Ever since your first post I immediately disabled the port forwarding rule for 22 and now I can delete it. I feel safe again
-
@tomsawyer2k5 so can you auth with your username and password with just a ssh client like putty?
What ticks me off the most, is yeah I get it you hire billy bob to read through your script.. I don't blame billy - they are not network engineers. Who I blame is the idiot that wrote the script in the first place ;)
I feel for the poor guy that doesn't actually understand what he is trying to support, he just wants a job and he can read etc.. And they say hey its simple just run through the script..
In no scenario would I ever have to "port forward" to access some service on the internet.. If that is in their script the guy creating the script is an idiot.. Its not billy the help desk guys fault, he doesn't know any better.. If was told to read off a script for how to do brain surgery I would be in the same place..
The best thing to do when calling for support is to ask to be escalated - can I actually talk to an engineer level, level 3 is the level is prob where you need to start to actually get somebody that understand how it works.. If they can not fix it, they they need to talk to the developers, etc.. Because at that level they know/understand how it is suppose to work, etc..
But what I can tell you with 99.999% confidence is if you rules are any any (default) and you can not talk to some service - its on the service providers side.. pfsense out of the box doesn't do anything other than route your traffic.. Hope you get it sorted.
-
@johnpoz Somehow the issue got escalated to a senior engineer without me asking for it :)
This engineer wants to compare configurations between a previously setup workstation, which was used to connect to the company's previous billing company, to the Zirmed configuration on the current workstation. Hopefully within the configuration files of the software they can spot some discrepancies and then adjust it to work with Zirmed. Besides this I'm waiting for the billing person and this engineer to solve the issue amongst themselves until they need me for something.
Yeah it's sad that some of these scripts are so out of touch with reality at times. They should be updating their script with feedback from the support people to have a better customer service experience, but this doesn't always happen or at least doesn't happen right away. Though they should immediately cut out the part of the script that suggests forwarding Port 22 as a possible solution
-
@tomsawyer2k5 if you don't mind let us know the end of the story..
-
@johnpoz So I finally got the end of the story. For some reason I wasn't included in the email loop and had to email them today to find out what's going on. Basically they told me everything is resolved (typical) and I had to ask what the root cause of the problem was. They gave me a response that goes something like "I copied the configuration file from a known working computer and put in the non-working computers and everything magically worked. The settings were the same between the configuration files and don't know how it started working."
This "working computer" they mention was basically a computer that was no longer used for billing purposes and was being used by another non-billing person.A few things still puzzle me, obviously. Like how can a program start working when copying over a configuration file that had the "same settings". If it were me, I would've done a compare between the two files before overwriting the intended target file so I can make a note of it. I mean there must've been SOMETHING different otherwise a mere copy and paste wouldn't work, unless the program has some kind of bug where it only updates settings within the program itself when the file on the drive has been modified somehow
The next thing is how or why they needed an existing configuration file to fix things instead of double-checking the lines that affected that very functionality. Then again, maybe it was a missed comma or semicolon (never seen the configuration file so guessing) that messed the non-working file.Anyway NOT the explanation I was hoping for as I'd prefer a more detailed explanation on why things broke, but can't argue with the outcome. Still, "Open Port 22"
Never again -
@tomsawyer2k5 glad to hear its working.. Yeah that sort of explanation amounts to we don't have a freaking clue to what we are doing..
It could have been a bad config, if its ssh based, ie sftp - could of been key they were using for auth, could of been different username, might of had bad ssh ciphers set, etc. There are loads of things that it could be - without the connection logs of it trying to connect to see where it was failing in the connection? For all we know it might of been pointing to wrong IP? or fqdn..
Can you get your hands on these configs and do a compare, or take it they overwrote the bad config with the good?
-
@johnpoz They already overwrote the bad config. sigh So I can't do anything on my end anymore.
-
@tomsawyer2k5 other than maybe setup a new machine with the software.. I would assume it should have the details to login built in, or ask the user for the info, like their username and password, etc..
For all we know the machine that was not working, they put in some bad info when it asked them.. Typo'd IP or fqdn they were suppose to put into the config on setup, or username/password, etc.
