easy question, routing problem

[IDS_1]

Hello,

I think it's an easy question, but I can't solve it.

This is the situation.

We have two routers.

Router 1 (bintec RT1202) has two ethernet interfaces with different subnets sub1 (172.16.10.0/24), sub2 (172.16.20.0/24).

Router 2 is our palo alto PA-200. It has one ethernet interface sub1(172.16.20.0/24)(just for the test).

Now I want to make a ping, from a pc which is connected at router1 sub1 with (default gateway is the ip of router1 sub1), to the ip address of the palo alto.

Therefore I have to define a virtual router with a static route on the palo alto: destination - 172.16.10.0/24, interface - ethernet1, next hop - ip address 172.16.20.10 (the ip address of the router 1 sub2).

I don't get a reply of the ping. When I make the ping on the "cli" of router1 to the palo alto, I get a reply, also whe I make a "nat" over the router1 sub2 interface.

Can anyone help?

regads

Joachim

[mikand]

So you have a setup like:

R1:

int1 172.16.10.0/24

int2 172.16.20.0/24

R2:

int1 172.16.20.0/24

How come your PA only have one interface setup?

Also if R1-int2 is attached to R2-int1 (either directly or through a switch) you wont need to setup any routing in R1 for it to send the packets the correct way. However R2 will need either a default route or a route for 172.16.10.0/24 which points back to the ip of R1-int2.

Also if you want the PA to respond to pings you need to create a management-profile where you select only "ping" and attach this management-profile to the interface with the particular subnet (R2-int1 in this case if the above list is correct).

[IDS_1]

Hello,

thank you for your response.

>>So you have a setup like:

>>R1:

>>int1 172.16.10.0/24 (172.16.10.10)

>>int2 172.16.20.0/24 (172.16.20.10)

>>R2:

>>int1 172.16.20.0/24 (172.16.20.11)

>>How come your PA only have one interface setup?

It's just for the test. Normaly there is a additional pppoe interface.

>>Also if R1-int2 is attached to R2-int1 (either directly or through a switch) you wont need to setup any routing in R1 for it to send the packets the correct way. However R2 will need either a default route or a route for 172.16.10.0/24 which points back to >>the ip of R1-int2.

On R1 is not routing defined. On R2 I have defined a virtual router like this: destination - 172.16.10.0/24, interface - ethernet1, next hop - ip address 172.16.20.10

>>Also if you want the PA to respond to pings you need to create a management-profile where you select only "ping" and attach this management-profile to the interface with the particular subnet (R2-int1 in this case if the above list is correct).

I allowed the ping on the interface on R2, which I can check from the command line interface from R1. Here I can ping the R2. It must be a routing problem on the R2.

For your understanding, we want to do the following:

A pc on R1 int1 should have internet access. The R2 should make the access over pppoe. Therefore I need the backrouting from R2 int1 to R1 int1.

This is an existing network and at the moment we make the internet access with a bintec router, which should be replaced with the palo alto.

Regards

Joachim

[mikand]

1) Could you paste the "show ip route" of R1 aswell as "show routing" from R2 (login through CLI or SSH)?

2) Could you in R2 verify by looking at the traffic log that the ping from client at R1 arrives to your device?

As debug setup a rule in R2 which is similar to:

srczone: internal

dstzone: internal

srcip: <ip of client at R1>

dstip: 172.16.20.11

appid: any

service: any

options: log on session start, log on session end

if this is a live equipment then set action to deny otherwise, if possible, set it to allow (just during the debug - dont forget to remove this rule once you are done).

Then when you send a ping from client at R1 you should see this hit the R2 in its traffic logs.

Im thinking if the management profile only allows srcip from the same subnet as the interface is using (which could explain why a ping from R1 towards R2 works but not when client at R1 pings through R1).

A further debug is to setup a tcpdump on the link between R1 and R2 to verify that the icmp echo request actually do leave R1 and that the R2 responds with an icmp echo respond.

You could have some blocking ACL in R1 or that the client itself at R1 doesnt have its default route set to R1 but only a static route for this subnet (172.16.10.0/24) or for that matter a local firewall on the client which prohibits the client to send or receive these icmp packets.

[IDS_1]

>>1) Could you paste the "show ip route" of R1 aswell as "show routing" from R2 (login through CLI or SSH)?

R1

Destination IP      Address Netmask      Gateway           Interface           Metric           Type      Protocol  

172.16.10.0           255.255.255.0          172.16.10.10     LAN_EN1-0           0              Direct     Local  

172.16.20.0           255.255.255.0          172.16.20.10     LAN_EN1-4           0              Direct     Local

R2

admin@PA-200> show routing fib

total virtual-router shown :              1

--------------------------------------------------------------------------------

virtual-router name: Router01

interfaces:

   ethernet1/4 ethernet1/1

route table:

flags: u - up, h - host, g - gateway

maximum of fib entries for device:                 1000

number of fib entries for device:                  3

maximum of fib entries for this fib:               1000

number of fib entries for this fib:                3

number of fib entries shown:                       3

id      destination           nexthop            flags  interface          mtu

--------------------------------------------------------------------------------

81      172.16.10.0/24        172.16.20.10       ug     ethernet1/1        1500

80      172.16.20.0/24        0.0.0.0            u      ethernet1/1        1500

79      172.16.20.11/32       0.0.0.0            uh     ethernet1/1        1500

>> Then when you send a ping from client at R1 you should see this hit the R2 in its traffic logs.

I created a security rule which allows the traffic and I can see at the monitor:

Receive Time

Type

From Zone     To Zone     Source

Source User      Destination     To Port Application     Action     Rule

Bytes

11/06 13:20:11     end    trust test    trust test    172.16.10.123

172.16.20.11    0    ping

allow    TEST eth1    74

>>Im thinking if the management profile only allows srcip from the same subnet as the interface is using (which could explain why a ping from R1 towards R2 works but not when client at R1 pings through R1).

It's not only the ping, the complete network traffic into the internet is not working, and therefore you don't need a management profile, and I don't get an error in the log files

>>A further debug is to setup a tcpdump on the link between R1 and R2 to verify that the icmp echo request actually do leave R1 and that the R2 responds with an icmp echo respond.

When I take pc instead of the palo alto, I get a ping reply, so I have to search the error on the palo alto.

>>You could have some blocking ACL in R1 or that the client itself at R1 doesnt have its default route set to R1 but only a static route for this subnet (172.16.10.0/24) or for that matter a local firewall on the client which prohibits the client to send or >>receive these icmp packets.

When I take pc instead of the palo alto, I get a ping reply, so I have to search the error on the palo alto.

regards

Joachim

[mikand]

The routing looks good and you have obviously connected R1 to the correct interface of R2 (otherwise this allowed traffic shouldnt be visible).

Regarding your security rules... do you in the bottom of this list have a rule such as:

srczone: any

dstzone: any

srcip: any

dstip: any

appid: any

service: any

options: log on session end

action: deny

If you do and still no blocked stuff shows up in traffic log I would expect some kind of layer1 fault.

Like bad cable or bad interface.

A "show interface ethernet1/1" (I dont remember if you need "hardware" in the end aswell to get the counters of if the counters is only available through "debug data-plane") would be interresting, also do the equal on R1.

[IDS_1 · Accepted solution]

So at first,

thank you for the your great help.

The problem is solved.

I think it was a combination of my understanding how the interfaces of the palo alto work and a misconfiguration.

I made the configuration completly new. And after I configured again a the second interface at the palo alto the routing was working (at my first try not, and I think I'd configured it the same way).

Again,

thank you for your help.

regards

Joachim