Port Forwarding Failing
-
Good morning all!
After a chat with stephenw10 (thanks for your advice), I'm still having trouble port forwarding for credit card terminals. Luckily I've got a second internet connection at current so just using that with a BT hub for all card machines. I can't seem to be able to communicate with the CC servers.
I've opened up the specified ports via LAN, WAN and Port forwarding. Currently the machines are on a dynamic IP via DHCP from pf. As I was unsure how to change the machines to static I decided to make an alias with the entire IP range on the network and used this in the NAT. Should this work or is this where it's failing?
I've also been given a URL(IP), how will I be able to allow the machines to communicate with these IPs?
At this point, I'm really lost and have tried pretty much everything but the static IP.
I was also wondering, with port forwarding, is the port only opened when a client is requesting/broadcasting? As I've tried a port checker numerous times and has always come back closed :(
-
I've opened up the specified ports via LAN, WAN and Port forwarding. Currently the machines are on a dynamic IP via DHCP from pf. As I was unsure how to change the machines to static I decided to make an alias with the entire IP range on the network and used this in the NAT. Should this work or is this where it's failing?
You can't port forward to a range of internal addresses, only one. You will need to set up a separate external alias to forward to each static address inside. This alone would prevent your setup from working correctly at least, so initially you'll have to set the machine addresses statically and create the port forwards before you can troubleshoot anything else.
-
Thanks for your reply, I had a feeling this would be the case (why didn't I try static sooner >:()
Sorry for a completely amateur question but if I've been given a URL by the service provider (eg. server.domain.com) and port number xxxx how would I port forward to that server without pf thinking something is dodgy from a request to go to that server?
Could I make an alias Host of say server.domain.com:xxxx and use that in destination?
-
huh? where does server.domain.com point? To your public IP, then forward port xxxx to where you want it to go on inside, be it to xxxx as well or yyyy.
Where are you trying to access server.domain.com:port from - the outside? Or inside your network?
So this url you were given was for your clients to access from behind pfsense to the public internet? That would would out of the box.. You would have to do nothing since the default lan rule is any any. Can you not access the internet from behind pfsense. Not sure why you think you need to setup any special nat or forwarding? if just trying to access fdqn: port on the internet.
-
By default pfsense allows all traffic out from the trusted side (LAN) to the untrusted (WAN), so your outbound NAT should take care of the port forwarding automatically. You can test whether the remote server/port is available by running a telnet session from a host inside your LAN to the remote host (eg: 'telnet server.domain.com xxxx' - where 'xxxx' is the port number). How you configure this on your terminals is really a setting you'll have to find out from the equipment provider.
-
Having looked back over your posts, I should say that I've made few assumptions here. 1) That you have credit card terminals running in your LAN and that 2) the remote server where those terminals should communicate is hosted by a bank/card provider. I am assuming there is a reason for your terminals to be accessible via port forwarding from your WAN side, but it may be that you've simply assumed they have to be through a misunderstanding of sorts. I have credit card terminals running on our own network here and though they need to communicate with the bank at the other end there is no need for the terminals to be visible from the internet side.
As ever, it would be helpful if perhaps you could clarify what you're trying to achieve rather than ask specifically how to do what you think you need to do.
-
huh? where does server.domain.com point? To your public IP, then forward port xxxx to where you want it to go on inside, be it to xxxx as well or yyyy.
Where are you trying to access server.domain.com:port from - the outside? Or inside your network?
The card terminals access the server from inside to out. However, I believe it's a two way communication so I suppose after creating a NAT rule I'd also need to port forward port xxxx too.
Having looked back over your posts, I should say that I've made few assumptions here. 1) That you have credit card terminals running in your LAN and that 2) the remote server where those terminals should communicate is hosted by a bank/card provider. I am assuming there is a reason for your terminals to be accessible via port forwarding from your WAN side, but it may be that you've simply assumed they have to be through a misunderstanding of sorts. I have credit card terminals running on our own network here and though they need to communicate with the bank at the other end there is no need for the terminals to be visible from the internet side.
As ever, it would be helpful if perhaps you could clarify what you're trying to achieve rather than ask specifically how to do what you think you need to do.
Ah I see, I figured that the devices sent and received via port xxxx. I should probably clarify this with the provider. I was only advised to port forward this making me think it was to be bi-directional.
At this moment in time, it's not communicating with the bank. I have been given two port numbers and with those numbers, associated URLs. I would like to be able to communicate with these servers outbound via the given ports. I'll have to check later whether they require inbound port forwarding.
-
My guess is that you won't have to worry about inbound port forwarding to your terminals at all. We don't have to at my office. All you'll need is to point the terminals to the remote server on port 'xxxx' and that should do the trick. Unless you've hand-crafted your outbound NAT and firewall rules this should work out of the box.
-
My guess is that you won't have to worry about inbound port forwarding to your terminals at all. We don't have to at my office. All you'll need is to point the terminals to the remote server on port 'xxxx' and that should do the trick. Unless you've hand-crafted your outbound NAT and firewall rules this should work out of the box.
I have gotten rid of the any (lan) to any and handpicked all the ports. However, I suppose I could reenable this and block the ports I don't want in the network (torrents etc). It's not the best but all internal machines are trusted I guess and would save a bit of a headache.
My outbound NAT is automatic (I'm not getting involved with that one ;) )
I'll give this a try later on. I don't see why it wouldn't work. I think the number one fault is the whole IP range in an alias.
I've reserved some IPs from the DHCP so I've got room!
Thanks guys, I'll let you know how I get on later.
-
I have gotten rid of the any (lan) to any and handpicked all the ports. However, I suppose I could reenable this and block the ports I don't want in the network (torrents etc). It's not the best but all internal machines are trusted I guess and would save a bit of a headache.
I've worked with a lot of firewalls in my professional career and IMHO it is always best to start with a 'block all' approach and simply open up what you need to. It's the default that most professional (meaning 'expensive') firewalls such as Cisco, Palo Alto and Juniper adhere to. In truth you'd be saving yourself a lot of aggro by just allowing the ports you need rather than blocking everything you want to stop.
Just an afterthought. Good luck.
-
Thank you all. I did it and it's all good.
I talked with the supplier and figured out the exact settings.
I decided to keep my handpicked ports and put the card machines onto static IPs as I wasn't too sure if the CC machine would request a new DHCP lease after the lease had expired.
Anyways, all good. Thanks guys :)
-
So you don't need any forwarders? From muswell, and how I read your post it seems that is where the client needs to talk, not what needs to talk to the client. Your machines behind pfsense being the client.
