• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 366
  • Last Modified:

Restricting port forwards by classless IP.

I'm getting a managed device added to my network. The vendor has requested specific port forwards from specific hosts.

I usually add port forwards in this fashion:

access-list outside_access_in permit tcp any host 4.2.2.4 eq 443
static (inside,outside) tcp 4.2.2.4 443 10.10.10.5  443 netmask 255.255.255.255 0 0

From the research I've done it looks like I can lock down the IP that is allowed to connect to port 443 using the following rules:

access-list outside_access_in permit tcp host 5.5.5.5 interface outside eq 3389
static (inside,outside) tcp 4.2.2.4 443 10.10.10.5  443 netmask 255.255.255.255 0 0

That will restrict access to only hosts coming from the 5.5.5.5 network.

What I need to do is restrict to a classless IP.

Here are the port forwards the vendor wants.

1.1.1.1/32
1.1.1.2/32
1.2.1.1/25
1.3.1.1/25
all forwarded to ports 443 and 22

2.2.2.2/24
2.2.3.2/24
forwarded to 443

3.3.3.3/29
3.3.3.4/29
forwarded to 6860 and 6861

Can someone show me the correct syntax for this?
Thanks
0
NickGT20
Asked:
NickGT20
  • 5
  • 5
1 Solution
 
rsivanandanCommented:
You have the answer within your question itself;

Take a closer look at the access-list;

>>access-list outside_access_in permit tcp host 5.5.5.5 interface outside eq 3389

In the above "host 5.5.5.5" means a SINGLE device with an IP address of 5.5.5.5

will be allowed and not the network.

So similarly if you add multiple entries for other hosts as well, your done!

Cheers,
Rajesh
0
 
NickGT20Author Commented:
So can I enter a classless IP right into the rule? Is the following correct?

access-list outside_access_in permit tcp host 1.1.1.1/32 interface outside eq 443
access-list outside_access_in permit tcp host 1.1.1.2/32 interface outside eq 443
access-list outside_access_in permit tcp host 1.2.1.1/25 interface outside eq 443
access-list outside_access_in permit tcp host 1.3.1.1/25 interface outside eq 443

access-list outside_access_in permit tcp host 1.1.1.1/32 interface outside eq 22
access-list outside_access_in permit tcp host 1.1.1.2/32 interface outside eq 22
access-list outside_access_in permit tcp host 1.2.1.1/25 interface outside eq 22
access-list outside_access_in permit tcp host 1.3.1.1/25 interface outside eq 22

static (inside,outside) tcp 4.2.2.4 443 10.10.10.5  443 netmask 255.255.255.255 0 0
static (inside,outside) tcp 4.2.2.4 443 10.10.10.5  22 netmask 255.255.255.255 0 0
0
 
NickGT20Author Commented:
So I found out that my syntax is not correct.
The static lines are fine, but I get an error when I try to apply the access-list. Invalid IP address.

My current port forwards look like this:
access-list outside_access_in permit tcp any host x.x.x.61 eq 5500
static (inside,outside) tcp x.x.x.61 5500 10.8.5.15 5500 netmask 255.255.255.255 0 0
0
Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

 
rsivanandanCommented:
>>access-list outside_access_in permit tcp host 1.1.1.1/32 interface outside eq 443

The above is incorrect,

access-list outside_access_in permit tcp host 1.1.1.1 interface outside eq 443

You don't need to specify the subnet mask as 32, the keyword 'host' does specify that it is a 32 bit mask.

Cheers,
Rajesh
0
 
NickGT20Author Commented:
What about for the other subnets?
/25
/29
/24
0
 
rsivanandanCommented:
It doesn't matter Nick, when you specify the host option, what it looks for is the ip address portion considering it as a host. In an IP header, there is no subnet mask, so your pix firewall doesn't care at all.

The subnet mask comes into play when your pix is doing routing... or anything that is doing routing....

1.1.1.1/25 -> means nothing to pix

Go ahead and configure it, you can count on me :-)

If you don't believe, then you could test it as well. Configure one of them, then go to another ip address in the same network and see if it can reach the service.

Cheers,
Rajesh
0
 
NickGT20Author Commented:
I appreciate all the help Rajesh. I'm still a little unclear about something though.

The vendor says to only allow connections to port 443 from 192.134.191.128/25.
That CIDR includes all IPs from 192.134.191.128 to 192.134.191.255.

So if I just put in 192.134.191.128 in the access rule, they aren't going to be able to connect on any of the other IPs.
So do I have to put in 128 different access rules? Or is there a better way?
0
 
NickGT20Author Commented:
I figured it out. I was entering the command wrong.
Rajesh, the host entries were fine. The problem was in the CIDR with /29 and /25 masks. I didn't realize I had to add these as networks. That was why it wasn't working for me.
So I wanted 192.134.191.128/25.

You told me to just add 192.134.191.128 and disregard the /25. this is wrong though. I need everything in that subnet /25 to be able to access the port through the firewall.

What I needed was to add 192.134.191.128 255.255.255.128.

That solved my problem.
0
 
rsivanandanCommented:
Oh jeez, the whole context we were talking was individual ip addresses or at least that is what my impression was.

If you want *all* the network to be allowed then you ofcourse need to have it configured the way you have now.

Glad to know you finally solved it.

Cheers,
Rajesh
0
 
rsivanandanCommented:
thnx.

Cheers,
Rajesh
0

Featured Post

What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now