PIX 515e and 1841 Router - need help with setup

Answered Question
Feb 10th, 2009
User Badges:

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 4 months 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 4 months 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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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


Regards,

Ali

Tshi M Tue, 02/10/2009 - 06:18
User Badges:
  • Silver, 250 points or more

Hope it helps. Please rate :-)

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

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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

Actions

This Discussion