PIX 515e and 1841 Router - need help with setup

Answered Question
Feb 10th, 2009

Hi

We have an 1841 Router with a Lease Line coming through on it. We have been advised to use a Firewall between the 1841 and our LAN, so we are using a 515e which we have in the office.

The scenario up until now has been with regards to our 515e, that on the Internal port, we have our entire IP range i.e. abc.def.ghi.0/24 (not a private IP range) and on the External port, we have a single public IP address of a different range.

Now we have a new public IP range, i.e. jkl.mno.pqr.0/24 (coming from the Lease Line through the 1841) but dont have a single public IP address for the External port.

Can we use an IP address from the jkl.mno.pqr.0/24 and single it out for the External port ? will this work ? If not, then what is the workaround or solution for this please ?

Unfortunately, we dont have access to the 1841, but we do to the PIX.

We really appreciate any help on this and a million thanks in advance.

Regards,

Ali

Correct Answer by Tshi M about 8 years 1 week ago

Hi Tahir,

If you really need an inside ACL, create a new ACL and apply it to the inside interface. I also don't understand that it is an implicit rule. I thought deny at the end of an ACL statement was the implicit rule.

In any case, just create a new one (with a new name :-) and apply it to the inside Interface. You can always clean up the config later.

Correct Answer by Tshi M about 8 years 1 week ago

sorry. Not sure but have you tried removing that line from your configuration? Do you really need an inside ACL? If you really need an inside ACL, create a new one and apply it to the inside interface. I think that will be the best shortcut to take.

rgds,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
Tshi M Tue, 02/10/2009 - 05:10

Hi,

Are you planning to use the new range pass the firewall? It will be a waste to use /24 on your external interface. I will suggest you break down the /24 into multiple subnets and use like /30 on your external firewall and the router port facing your external firewall interface. And then in your firewall, you will use the remainder of the addresses if you need to. What address is currently assigned to the router port facing your external firewall?

smbtest12 Tue, 02/10/2009 - 06:04

Hi Etienne

Thank you for your reply. We managed to get a little more info from the line engineers. They said that we should place the new public IP range 194.xxx.yyy.0/24 on the Ext Port of the PIX and that our LAN Range 192.168.www.0/24 should flow from the Int Port of the PIX. And then they suggested that we should use NATTING inside the PIX to translate from the 194 range to 192 and vice versa.

The current IP on the 1841 port that faces the PIX (and is connected with X-over cable) is 194.xxx.yyy.1

What would you suggest on this ?

Thank you

Ali

Tshi M Tue, 02/10/2009 - 06:09

That should work just fine. You can PAT to the external interface of your firewall if you don't have any web or other applications that need Public address. All you need to do here is to change your exernal firewall interface to a 194 and also change the route outside to 194.xxx.yyy.1

Regards,

smbtest12 Tue, 02/10/2009 - 06:15

Etienne, thank you for your response. We will try it out and see how it goes from there.

Regards,

Ali

smbtest12 Wed, 02/11/2009 - 06:08

Hi

We tried out the suggestion yesterday and are now having issues with the NATTING itself.

We have at present a simple setup which we aim to use to expand.

Internet router 194.xxx.yyy.1 --> 194.xxx.yyy.2 = External PIX Internal 192.168.7.1 <-- Switch

At the switch we have two pcs

1. Laptop 192.168.7.223

2. PC 192.168.7.113

For both the Laptop and PC, we want to use static NAT to translate as follows

192.a.b.223 ==> 194.xxx.yyy.223

192.a.b.113 ==> 194.xxx.yyy.113

All the internal hosts can ping each other including Ethernet1

From outside the setup we can ping Ethernet0 on the PIX but cannot ping out from Ethernet0 to the internet

Any ideas ? really appreciate your help

thanks

Tshi M Wed, 02/11/2009 - 06:24

Hi Tahir,

If I understand this correctly, your internal firewall address is 192.168.7.1, you have two internal addresses that you would like to NAT to two external addresses. Correct? Could you please poste your firewall configuration? Remove passwords.

Regards,

p.s. your static should like this:

nat (inside) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface

static (inside,outside) 194.xxx.yyy.223 192.168.7.223 netmask 255.255.255.255

static (inside,outside) 194.xxx.yyy.113 192.168.7.113 netmask 255.255.255.255

smbtest12 Wed, 02/11/2009 - 07:04

Etienne,

Yes that is correct, we have at the mo, two hosts which need two different external IPs translated to from their internal IPs.

The config is as follows

interface Ethernet0

nameif outside

security-level 0

ip address 194.xxx.yyy.2 255.255.255.0

ospf cost 10

!

interface Ethernet1

nameif inside

security-level 100

ip address 192.168.7.1 255.255.255.0

ospf cost 10

mtu outside 1500

mtu inside 1500

ip verify reverse-path interface outside

ip verify reverse-path interface inside

icmp unreachable rate-limit 1 burst-size 1

icmp permit any outside

icmp permit any inside

arp timeout 14400

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0

static (inside,outside) 194.xxx.yyy.113 pixserver netmask 255.255.255.255

static (inside,outside) 194.xxx.yyy.223 supportlaptop netmask 255.255.255.255

access-group outside_access_in in interface outside

access-group inside_access_in in interface inside

route outside 0.0.0.0 0.0.0.0 194.xxx.yyy.1 1

thanks

Ali

Tshi M Wed, 02/11/2009 - 07:15

Hi Tahir,

Is the problem just with ping? Can you browse the Internet? If not, what is the traceroute output? Do you have any logs from the PIX? is the translation taking place, sh xlate

regards

smbtest12 Wed, 02/11/2009 - 07:36

Hi,

We cannot browse the internet as well as not being able to ping.

If we conduct a PAcket Trace from within the Pix using 192.168.7.113 as the source and an outside (internet) IP address as the destination, the packet goes through. But tracert doesn;t work from the Laptop/PC itself.

sh xlate

2 in use, 5 most used

Global 194.xxx.yyy.113 Local pixserver

Global 194.xxx.yyy.223 Local supportlaptop

thanks

Ali

Tshi M Wed, 02/11/2009 - 07:41

what is your ACL? Do you have any logs? What is the default gateway of your PC/server and switch?

smbtest12 Wed, 02/11/2009 - 07:56

Default Gateway is 192.168.7.1 for all the internal hosts

access-list inside_access_in extended permit ip 192.168.7.0 255.255.255.0 192.168.7.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit tcp 192.168.7.0 255.255.255.0 192.168.7.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit udp 192.168.7.0 255.255.255.0 192.168.7.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit icmp 192.168.7.0 255.255.255.0 192.168.7.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit tcp any any eq domain

access-list inside_access_in extended permit icmp any 194.xxx.yyy.0 255.255.255.0 echo

access-list inside_access_in extended permit icmp any 194.xxx.yyy.0 255.255.255.0 echo-reply

access-list inside_access_in extended permit tcp any 194.xxx.yyy.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit udp any 194.xxx.yyy.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit ip any 194.xxx.yyy.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit icmp any 194.xxx.yyy.0 255.255.255.0 time-range Never_End

access-list inside_access_in extended permit tcp any any eq www

access-list outside_access_in remark terminal services

access-list outside_access_in extended permit tcp any eq 3389 192.168.7.0 255.255.255.0 eq 3389

access-list outside_access_in extended permit icmp any 192.168.7.0 255.255.255.0 echo

access-list outside_access_in extended permit icmp any 192.168.7.0 255.255.255.0 echo-reply

access-list outside_access_in extended permit tcp any object-group Terminal_Services eq 3389 inactive

access-list outside_access_in extended permit tcp any object-group SSH eq ssh inactive

access-list outside_access_in extended permit tcp any object-group CRM_5555 eq 5555 inactive

access-list outside_access_in extended permit udp any object-group DNS eq domain inactive

access-list outside_access_in extended permit tcp any object-group FTP eq ftp inactive

access-list outside_access_in extended permit tcp any object-group FTP_DATA_20 eq ftp-data inactive

access-list outside_access_in extended permit tcp any object-group HTTP eq www inactive

access-list outside_access_in extended permit tcp any object-group HTTPS eq https inactive

access-list outside_access_in extended permit tcp any object-group IMAP eq imap4 inactive

access-list outside_access_in extended permit tcp any object-group OCS2007 eq 5061 inactive

access-list outside_access_in extended permit tcp any object-group POP3 eq pop3 inactive

access-list outside_access_in extended permit tcp any object-group SCOM_5723 eq 5723 inactive

access-list outside_access_in extended permit tcp any object-group SMTP eq smtp inactive

access-list outside_access_in extended permit ip any 192.168.7.0 255.255.255.0 time-range Never_End

access-list outside_access_in extended permit tcp any object-group VPN eq pptp inactive

thanks

Tshi M Wed, 02/11/2009 - 08:09

Hi Tahir,

I was hoping to see a log file as well. In any case, please remove the inside ACL as a troubleshooting step. you can also setup a syslog server and use kiwisyslog or the ASDM log viewer to see what taking place.

smbtest12 Wed, 02/11/2009 - 08:28

would this help

6|Feb 11 2009|16:21:11|302014|200.80.177.223|194.xxx.yyy.95|Teardown TCP connection 13371 for outside:200.80.177.223/4204 to outside:194.xxx.yyy.95/445 duration 0:00:30 bytes 0 SYN Timeout

6|Feb 11 2009|16:21:11|302014|80.123.109.132|194.xxx.yyy.32|Teardown TCP connection 13370 for outside:80.123.109.132/1827 to outside:194.xxx.yyy.32/445 duration 0:00:30 bytes 0 SYN Timeout

6|Feb 11 2009|16:21:10|302013|95.28.101.139|194.xxx.yyy.114|Built inbound TCP connection 13381 for outside:95.28.101.139/3361 (95.28.101.139/3361) to outside:194.xxx.yyy.114/445 (194.xxx.yyy.114/445)

6|Feb 11 2009|16:21:09|302013|80.99.137.82|194.xxx.yyy.112|Built inbound TCP connection 13380 for outside:80.99.137.82/2628 (80.99.137.82/2628) to outside:194.xxx.yyy.112/445 (194.xxx.yyy.112/445)

6|Feb 11 2009|16:21:06|302013|82.49.105.89|194.xxx.yyy.81|Built inbound TCP connection 13379 for outside:82.49.105.89/1390 (82.49.105.89/1390) to outside:194.xxx.yyy.81/445 (194.xxx.yyy.81/445)

6|Feb 11 2009|16:21:03|302013|88.28.63.24|194.xxx.yyy.22|Built inbound TCP connection 13378 for outside:88.28.63.24/2062 (88.28.63.24/2062) to outside:194.xxx.yyy.22/445 (194.xxx.yyy.22/445)

6|Feb 11 2009|16:21:02|302014|92.125.93.212|194.xxx.yyy.110|Teardown TCP connection 13368 for outside:92.125.93.212/24089 to outside:194.xxx.yyy.110/445 duration 0:00:30 bytes 0 SYN Timeout

6|Feb 11 2009|16:21:01|725007|pixserver||SSL session with client inside:pixserver/14832 terminated.

6|Feb 11 2009|16:21:01|302015|61.185.21.61|194.xxx.yyy.110|Built inbound UDP connection 13377 for outside:61.185.21.61/1265 (61.185.21.61/1265) to outside:194.xxx.yyy.110/1434 (194.xxx.yyy.110/1434)

6|Feb 11 2009|16:21:00|106015|pixserver|192.168.7.1|Deny TCP (no connection) from pixserver/14832 to 192.168.7.1/443 flags FIN ACK on interface inside

6|Feb 11 2009|16:21:00|302014|pixserver|192.168.7.1|Teardown TCP connection 13376 for inside:pixserver/14832 to NP Identity Ifc:192.168.7.1/443 duration 0:00:00 bytes 602 TCP Reset-O

6|Feb 11 2009|16:21:00|605005|0.0.0.0|0.0.0.0|Login permitted from 0.0.0.0/14832 to inside:0.0.0.0/https for user "enable_15"

6|Feb 11 2009|16:21:00|725002|pixserver||Device completed SSL handshake with client inside:pixserver/14832

6|Feb 11 2009|16:21:00|725003|pixserver||SSL client inside:pixserver/14832 request to resume previous session.

6|Feb 11 2009|16:21:00|725001|pixserver||Starting SSL handshake with client inside:pixserver/14832 for TLSv1 session.

6|Feb 11 2009|16:21:00|302013|pixserver|192.168.7.1|Built inbound TCP connection 13376 for inside:pixserver/14832 (pixserver/14832) to NP Identity Ifc:192.168.7.1/443 (192.168.7.1/443)

6|Feb 11 2009|16:21:00|302015|58.57.17.194|194.xxx.yyy.122|Built inbound UDP connection 13375 for outside:58.57.17.194/1035 (58.57.17.194/1035) to outside:194.xxx.yyy.122/1434 (194.xxx.yyy.122/1434)

6|Feb 11 2009|16:20:50|302013|196.40.50.33|194.xxx.yyy.13|Built inbound TCP connection 13374 for outside:196.40.50.33/4940 (196.40.50.33/4940) to outside:194.xxx.yyy.13/445 (194.xxx.yyy.13/445)

6|Feb 11 2009|16:20:47|302014|194.208.249.243|194.xxx.yyy.35|Teardown TCP connection 13363 for outside:194.208.249.243/1240 to outside:194.xxx.yyy.35/445 duration 0:00:30 bytes 0 SYN Timeout

6|Feb 11 2009|16:20:46|302015|221.233.242.4|194.xxx.yyy.29|Built inbound UDP connection 13373 for outside:221.233.242.4/2406 (221.233.242.4/2406) to outside:194.xxx.yyy.29/1434 (194.xxx.yyy.29/1434)

6|Feb 11 2009|16:20:44|302013|201.81.244.1|194.xxx.yyy.117|Built inbound TCP connection 13372 for outside:201.81.244.1/2643 (201.81.244.1/2643) to outside:194.xxx.yyy.117/445 (194.xxx.yyy.117/445)

Tshi M Wed, 02/11/2009 - 08:43

not really since it is showing most outside attempts.

Did you remove the inside acl for troubleshooting?

Try a telnet session to a web site on port 80 and take a look at your log. Having a real time log viewer might be helpful. this is a pretty simple setup and should work as is.

smbtest12 Wed, 02/11/2009 - 08:59

Yes we removed the inside rules.

It seems like after trying your telnet suggestion, that there is some sort of connectivity, but the following implicit rule is blocking access

access-list inside_access_in extended deny ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

this rule was inbuilt and does not actually appear in sh running-config, but the logs from the telnet session clearly point to this

we had a few earlier logs pointing to this too but we wrote a rule to override it as follows, but it doesnt seem to have any effect

access-list inside_access_in extended permit ip 192.168.7.0 255.255.255.0 192.168.7.0 255.255.255.0 time-range Never_End

thanks a lot

Ali

smbtest12 Wed, 02/11/2009 - 09:42

Sorry Etienne, forgot to ask you if you have any ideas about getting round this.

Thanks a lot

Ali

Correct Answer
Tshi M Wed, 02/11/2009 - 09:48

sorry. Not sure but have you tried removing that line from your configuration? Do you really need an inside ACL? If you really need an inside ACL, create a new one and apply it to the inside interface. I think that will be the best shortcut to take.

rgds,

smbtest12 Wed, 02/11/2009 - 10:13

Thanks, but its an implicit rule which is hard wired into the OS of the PIX. I have been trying to remove it, but in ASDM there is no option to delete and in Command Line it just doesnt appear.

thanks

Correct Answer
Tshi M Wed, 02/11/2009 - 10:19

Hi Tahir,

If you really need an inside ACL, create a new ACL and apply it to the inside interface. I also don't understand that it is an implicit rule. I thought deny at the end of an ACL statement was the implicit rule.

In any case, just create a new one (with a new name :-) and apply it to the inside Interface. You can always clean up the config later.

smbtest12 Thu, 02/12/2009 - 07:44

Etienne,

Sorry couldnt get back earlier. Your idea of removing the inside rules worked a treat. they were interfering with the connection, the implicit rule needs to be left as is (as far as i could figure out).

Thank you so much for your help. I may have other queries later on today as we are soon to finalise a new setup.

I really appreciate your help. Will rate your posts just now.

Regards

Ali

Tshi M Thu, 02/12/2009 - 08:21

Thanks much and I am happy that I was able to assist.

Actions

This Discussion