1. Home
  2. Cisco Systems
  3. routing on a PIX 515

routing on a PIX 515

I'm a bit of newbie, and have configured a few routers, but this is my first PIX firewall configuration. I've got a PIX 515 set up on an interior network to do some simple testing before I move it to be our firewall. The problem is that I can't get packets to across the firewall from the inside to the outside interface. And I've turned off the ICMP blocking. I'll include the relevant configuration below. I also wondered if the problem was just ICMP traffic, but HTTP packets don't cross the firewall either. In a few words:

1) from the network on the inside I can ping the inside interface 2) from the network on the outside I can ping the outside interface 3) From the firewall (console) I can ping both interfaces, the default gateway I've defined, and hosts on the inside network 4) But I can't ping from the host on the inside to the outside interface, and vice-versa.

I figure this is something pretty basic, but after searching thru a bunch of PIX tutorials on web and the Cisco site, I still can't find the answer. Here are the parts of the configuration I think are relevant:

! name the interfaces -- as expected nameif ethernet0 outside security0 nameif ethernet1 inside security100

! set the basic addresses ip address outside xxx.xxx.50.14 255.255.255.0 ip address inside xxx.xxx.65.193 255.255.255.0

route outside 0.0.0.0 0.0.0.0 xxx.xxx.53.1 2

! allow ping *temporarily* for debugging icmp permit any echo outside icmp permit any echo-reply outside icmp permit any echo inside icmp permit any echo-reply inside

! I tried this as an alternative way to turn off ICMP blocking. ! It doesn't seem to make any difference access-list ping_ok permit icmp any any access-group ping_ok in interface inside access-group ping_ok in interface outside

! I wondered if turning on RIP mattered, sortof like the ! command "ip routing" on a router. But it makes no difference ! these commands aren't in any of the basic configuration ! tutorials, but I was getting desperate. rip inside passive rip outside passive rip outside default _____________________________________

Like I said, I think I'm missing something that's pretty basic, I just don't know what it is.

Thanks in advance for any help.

BSquared

Reply to
"B Squared"
Loading thread data ...

In article , wrote: :is my first PIX firewall configuration. I've got a PIX 515 set

:4) But I can't ping from the host on the inside to the outside : interface, and vice-versa.

You can't do that (unless it's something now allowed in PIX 7.0(1)).

Reply to
Walter Roberson

Are you sure? I thought that the whole point of the configuration

icmp permit any echo outside icmp permit any echo-reply outside icmp permit any echo inside icmp permit any echo-reply inside

or

access-list ping_ok permit icmp any any access-group ping_ok in interface inside access-group ping_ok in interface outside

was to allow this.

But let's say that you are correct. The problem remains that I can't get http traffic, or any other tcp traffic, across the firewall. That is, a host on the inside network can't communicate with anything on the outside. And this is really the problem. In my problems with ping are just a specific instance of this more general problem.

Again, thanks in advance for any suggestions.

B Squared

Reply to
"B Squared"

|> In article , wrote: |> :is my first PIX firewall configuration. I've got a PIX 515 set

|> :4) But I can't ping from the host on the inside to the outside |> : interface, and vice-versa.

|> You can't do that (unless it's something now allowed in PIX 7.0(1)).

|Are you sure?

Yes.

|I thought that the whole point of the configuration

| icmp permit any echo outside

No, that permits the outside interface to accept (and respond to) icmp echo packets received on the outside interface.

|or

| access-list ping_ok permit icmp any any | access-group ping_ok in interface inside | access-group ping_ok in interface outside

access-group never has any effect on the traffic that can be handled by the PIX itself.

|But let's say that you are correct. The problem remains that I |can't get http traffic, or any other tcp traffic, across the firewall. |That is, a host on the inside network can't communicate with anything |on the outside. And this is really the problem.

Sorry, was it you that sent me the configuration in email the other day?

Reply to
Walter Roberson

Not me. But below are the parts of the configuration file that I

*think* are relevant, given what you've said. __________________

interface ethernet0 auto interface ethernet1 auto

! name the interfaces -- as expected nameif ethernet0 outside security0 nameif ethernet1 inside security100

! standard fixup protocol settings fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69

names !! allow host names

mtu outside 1500 !! as expected mtu inside 1500

! set the basic addresses ip address outside xxx.xxx.50.14 255.255.255.0 ip address inside xxx.xxx.65.193 255.255.255.0

! set the default route, I also tried 1 hop, and that didn't ! solve the problem route outside 0.0.0.0 0.0.0.0 xxx.xxx.53.1 2

! I wondered if turning on RIP mattered, sort of like the ! command "ip routing" on a router. But it makes no difference. ! These commands aren't in any of the basic configuration ! tutorials, but I was getting desperate. rip inside passive rip outside passive rip outside default

! set some standard timeouts timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 :00:00 ( the news group editor wrapped this line ) timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout uauth 0:05:00 absolute ________________________________

I think that covers everything that is important. The thing that surprised me about PIX was that there seems to be no equivalent to the commmand "ip routing" to turning routing on, nor is there an equivalent to the command "network xxx.xxx.xxx.000" that is assigned to set up routing between the interfaces. So I'm guessing these differences are just part of the way PIX works.

Thanks in advance for any suggestions.

B Squared

Reply to
"B Squared"

Two things :

  1. Add the command to the PIX to allow inside network ping outside world a. access-list outside_acl_in permit icmp any any b. access-group outside_acl_in in interface outside

Note : try this first, if no succeed, then go to next step.

  1. Make sure the ACL in the interface "inside" does not block the specific hosts to ping the outside world.

The IT Maniac BensonLei in HK

Reply to
Benson

Maybe you left it out of the config you posted, but I don't see any NAT statements. Even if you're using public IPs behind the pix, you at least need to add in a static statement. I.E. static (inside,outside) 152.x.x.x 152.x.x.x netmask 255.255.255.0

0 0
Reply to
Brian

Even if you don't want to use nat, you need to define at least one nat-statement. For example: nat (inside) 0 0 0 will pass traffic from the inside to the outside untranslated. You can also use the static command.

skrev i meddelandet news: snipped-for-privacy@scnresearch.com...

Reply to
TC

That's correct. You must set the nat command!!!

If you don't use nat set:

nat (inside) 0 0 0

When you use nat set:

nat (inside) 1 0 0 global (outside) 1 interface

With this global command set the nat pool 1 to the official internet address of the firewall. When you want to use static address translation with many officials ip addresses then use additionally:

static (inside,outside) OUTSIDE_IP INSIDE_IP netmask 255.255.255.255

I hope that helps.

Gerd

Reply to
Gerd EMail

After reading the replies, I'm sure that setting the basic nat configuration will do it.

Thanks for all your help

B Squared

Reply to
"B Squared"

In article , Gerd EMail wrote: :That's correct. You must set the nat command!!!

That is not accurate. If all of the host/port combinations that you want to let outside have static or nat 0 access-list then you do not need to use a nat 0 or nat/global pair.

:When you use nat set: :nat (inside) 1 0 0

I advise against using nat/global with 0/0 as the source. If your inside hosts start sending packets with IP addresses that do not belong to you, such as due to a virus or due to one of them having failed DHCP and taken on a 169.254.*.* address, then you will be permitting the packets out. The return packets won't have any way to get all the way back to the originating computer, but they will reach your PIX (because you nat'd to the interface IP), and they will have an effect on the remote system (such as contributing to a DDoS.)

Reply to
Walter Roberson

Not sure how you're recommending he pass traffic from the inside out without using either NAT or a static translation, but the problem you mention can be mitigated with an access-list on the inside interface. It's a good idea to do this anyway, to make sure that no one inside your firewall is spoofing an IP address. If your inside network is

10.1.2.0 255.255.255.0, then just set up an ACL, "access-list outgoing permit ip 10.1.2.0 255.255.255.0 any" then apply that to the inside interface: "access-group outgoing in interface inside"
Reply to
Brian

In article , Brian wrote: :Not sure how you're recommending he pass traffic from the inside out :without using either NAT or a static translation,

I said that don't recommend nating with 0/0 as the source.

:but the problem you :mention can be mitigated with an access-list on the inside interface.

And the problem can be eliminated by only nat'ing (or static) the address range that is to be permitted outside. For example,

nat (inside) 1 192.168.1.0 255.255.255.0

instead of

nat (inside) 1 0 0

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.