topic Re: Virtual Routers in General Topics

Virtual Routers

LCMember1607 — Tue, 24 Jul 2012 15:02:51 GMT

We recently switched ISPs and they assigned as a 32 address block that sits behind 1 address. i.e 71.100.100.192/27 block behind 71.100.100.50/30. We are now connected to the ISP with the PAN addressed as 71.100.100.50/30 with a default route destination of 71.100.100.49. That router knows of the IP block we have. Our mail server'sv outside dns is now configured on the new IP address block with a bi-directional static NAT rule.. We have been experiencing sent email issues.

What I want to do is setup an additional virtual router. One would be the publicVR and one would be the current defaultVR. What would be the easiest way to do this? Would this work? I also have some IPSec tunnels that terminate on the 71.100.100.50/27 interface. Would I terminate them on the 71.100.100.193/27 interface?

Public Zone | 71.100.100.50/27

PublicVR

| 71.100.100.193/27

DMZ Zone |

| 71.100.100.194/27

defaultVR

| 172.20.1.1

Private Zone |

Re: Virtual Routers

Bart_Jocque — Tue, 24 Jul 2012 15:16:09 GMT

Why would you create two VR's in the first place for a simple setup like this ?

On the publicVR you would still require a route towards your internal network and on the defaultVR you still require a router towards the internet.

So you will end up with two serial VR's with almost identical routing tables. I don't see how this would help you.

You should just assign the ip 71.100.100.50/27 to your untrust interface and 71.100.100.193/27 to your DMZ interface. And have one VR.

Bart.

Re: Virtual Routers

LCMember1607 — Tue, 24 Jul 2012 15:39:21 GMT

Our outside DNS OWA email address is within the 71.100.100.192/27 block. We are currently static bidirectional NATing from the inside out the

71.100.100.50/27. This is why some ISPs are blocking our email. So you are saying to connect another physical interface to a switch, for example, in the DMZ Zone and NAT out that interface?

| ethernet1/1

Public Zone | 71.100.100.50/27 current bidirectional static-ip NAT for email

defaultVR

| ethernet1/5

DMZ Zone | 71.100.100.194/27 bidirectional static-ip NAT here?

defaultVR

| ethernet1/6

Private Zone | 172.20.1.1

Re: Virtual Routers

bvandivier — Tue, 02 Oct 2012 18:44:34 GMT

Bill, could you share a topology of your existing environment? Perhaps your local Palo Alto Networks SE could offer some deployment advice. Have you considered reaching out to them?

Re: Virtual Routers

mikand — Wed, 03 Oct 2012 05:55:30 GMT

Unless I missunderstood something here is the topology:

Your public network: 71.100.100.192/27

Your linknet: 71.100.100.48/30 (your ip:71.100.100.50, your ISP ip: 71.100.100.49)

Since your ISP have 71.100.100.192/27 nexthop 71.100.100.50 you setup a layer3 interface on your PA which have:

zone: untrusted

71.100.100.50 255.255.255.252

default gw: 71.100.100.49

Then you just either place the whole 71.100.100.192/27 in zone dmz or you divide it into chunks (or for that matter use a RFC1918 range in your DMZ and NAT all traffic going to your dmz and trust zone).

Option1:

zone: untrusted

71.100.100.50 255.255.255.252

default gw: 71.100.100.49

zone: dmz

71.100.100.193 255.255.255.224

zone: trusted

172.20.1.1 255.255.255.0 (dont know how large subnet you got, just an example)

Range use for NAT (like SNAT trusted -> untrusted): 71.100.100.50/32

Option2:

zone: untrusted

71.100.100.50 255.255.255.252

default gw: 71.100.100.49

zone: dmz

71.100.100.193 255.255.255.240 (I cut the previous range in half, first half goes to dmz and second goes for nat)

zone: trusted

172.20.1.1 255.255.255.0 (dont know how large subnet you got, just an example)

Range use for NAT (like SNAT trusted -> untrusted): 71.100.100.208/28

Option3:

zone: untrusted

71.100.100.50 255.255.255.252

default gw: 71.100.100.49

zone: dmz

10.0.0.1 255.255.255.0 (using a RFC1918 range of choice, /24 in this example)

zone: trusted

172.20.1.1 255.255.255.0 (dont know how large subnet you got, just an example)

Range use for NAT (like SNAT trusted -> untrusted): 71.100.100.192/27