12-08-2014 02:30 PM
PAN-200
PAN OS 6
I am no networking guy, but he left, so there is me dealing with this.
We've embarked on a great project to renumber our IP addresses with very little thought in advance.
There aren't that many, we said. What could go wrong, we thought. Well, for starters, one host that I've cutover to the new scheme can't see 'the internet' but his brothers who are in the old scheme can.
eth1/2/3 are layer 2, in 'coloprovider_msrp' vlan
eth4 is layer3, with IP address of 209.59.29.193/26
That latter IP is the gateway address of the hosts behind the PA-200.
A well meaning person told me to make this a 10.1.1.x network so I plugged that into my CIDR calculator and
Address: 10.1.1.1
Netmask: 255.255.0.0
Network Address: 10.1.0.0/16
Broadcast: 10.1.255.255
So.
I gave my test host an address of 10.1.1.4, gateway 10.1.0.0
In PA-200, ETH4 added the IP address 10.1.0.0/16
And LO my host can ping 10.1.0.0. Great? It cannot ping the internet - my test IP being 8.8.8.8
What am I doing wrong, oh mighty keepers of the networking flame ...
To-be physical diagram
To-be Logical part one
To-Be Logical part two
Message was edited by: Brian Dunbar
12-08-2014 02:41 PM
It does not appear to be mentioned in either my few security or NAT policy.
12-08-2014 03:31 PM
FWIW here is my routing table before, and after ..
admin@tn-gateway-01> show routing route
flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp,
Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2
VIRTUAL ROUTER: default (id 1)
==========
destination nexthop metric flags age interface next-AS
0.0.0.0/0 209.59.31.137 10 A S vlan.10
10.50.1.1/32 10.50.1.1 10 A S tunnel.10
10.50.1.2/31 10.50.1.2 10 A S tunnel.10
10.50.1.4/30 10.50.1.4 10 A S tunnel.10
10.50.1.8/29 10.50.1.8 10 A S tunnel.10
10.50.1.16/30 10.50.1.16 10 A S tunnel.10
10.50.1.20/32 10.50.1.20 10 A S tunnel.10
209.59.29.192/26 209.59.29.193 0 A C ethernet1/4
209.59.29.193/32 0.0.0.0 0 A H
209.59.31.136/29 209.59.31.140 0 A C vlan.10
209.59.31.140/32 0.0.0.0 0 A H
dmin@tn-gateway-01> show routing route
flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp,
Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2
VIRTUAL ROUTER: default (id 1)
==========
destination nexthop metric flags age interface next-AS
0.0.0.0/0 209.59.31.137 10 A S vlan.10
10.1.0.0/16 10.1.0.0 0 A C ethernet1/4
10.1.0.0/32 0.0.0.0 0 A H
10.50.1.1/32 10.50.1.1 10 A S tunnel.10
10.50.1.2/31 10.50.1.2 10 A S tunnel.10
10.50.1.4/30 10.50.1.4 10 A S tunnel.10
10.50.1.8/29 10.50.1.8 10 A S tunnel.10
10.50.1.16/30 10.50.1.16 10 A S tunnel.10
10.50.1.20/32 10.50.1.20 10 A S tunnel.10
209.59.29.192/26 209.59.29.193 0 A C ethernet1/4
209.59.29.193/32 0.0.0.0 0 A H
209.59.31.136/29 209.59.31.140 0 A C vlan.10
209.59.31.140/32 0.0.0.0 0 A H
total routes shown: 13
12-08-2014 03:58 PM
Interesting: I tried to delete the reference to 209.59.29.193/26 from eth4 and was told ..
Validation Error:
deviceconfig -> system -> route -> destination -> 209.59.29.221 -> source -> address '209.59.29.193/26' is not a valid reference
deviceconfig -> system -> route -> destination -> 209.59.29.221 -> source -> address is invalid
config commit phase 1 aborted(Module: routed)
Config commit phase 1 aborted(Module: device)
panike_daemon phase 1 aborted(Module: ikemgr)
config commit phase 1 aborted(Module: dhcpd)
config commit phase 1 aborted(Module: varrcvr)
modhttpd phase 1 aborted(Module: l3svc)
Now .. 209.59.29.221 is one of two active directory servers I have. And of course, I have UserId talking to them. Ideas?
12-09-2014 05:59 AM
We really need to see a network topology and what the change of address affects old versus new.
Security policies and nat rule changes are already mentioned.
You seem to have vpn connections using static routes, this will likely mean you also need to make routing changes at those remote sites to reach the new network and then decommission the old one as well.
12-09-2014 07:42 AM
I need to update my diagrams to reflect changes that were inflicted last night - I'll do that and update. Not the very least because I need to update.
I did also create a support case last night (there was talk around the cage that the problem was a defective unit, and more talk that we should just nuke the firewall and reinstall from scratch, and I really, really, wanted to not do that). The support tech, Ceaser, ID'd the problem, in a nutshell, and my words, 'you are trying to route a non-routable network'.
He sent notes, and suggested we get in touch with our SE (I didn't know we had one of those!) but, in a nutshell, the fix is to take my three layer 2 interfaces and make them layer 3.
"Non-routable networks don't route". Seems so obvious after-the-fact.
12-09-2014 11:49 AM
For what it is worth, I have attached the to-be physical and logical diagrams.
12-12-2014 08:41 AM
HI,
10.1.0.0/16 is not a legal IP address to apply to your firewall - that's actually the subnet address.
Update your firewall to use 10.1.1.1/16 and place your hosts with 10.1.1.x (where x > 1!) addresses with a net mask of 255.255.0.0 and a default gateway of 10.1.1.1.
Good luck
aid
12-12-2014 10:00 AM
Interesting. Those documents are now out-of-date.
Last night I was on the phone with Wes, our Palo Alto SE (hi, Wes) and we did this ..
eth4 IP
10.1.0.1/16
209.59.29.193/26
Applied this IP to a host
IP 10.1.1.40
Subnet: 255.255.0.0
Gateway: 10.1.0.1
And it worked.
12-12-2014 10:07 AM
Sure, of 65535 addresses from 10.1.0.0 through to 10.1.255.255 - these two are the only ones you can't use as the gateway. Was bad luck choosing one of them. 😉
Did you get some suitable NAT sorted out with the PA SE?
12-12-2014 10:10 AM
Did you get some suitable NAT sorted out with the PA SE?
We did: kudos to Wes for being awesome.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
