cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jayh
Honored Contributor
Honored Contributor

Re: Need assistance routing Public IP natively w/o NAT

busy2 wrote:

Last piece of this is to restrict ports to the server connection xx.xxx.xxx.89/29

that would be and allow list in security zone dmz w destination dmz and ports selected "443,80,......" ?

^ btw ... this is a question??

This would be applied to the access-class for zone Public. You presently have allow list web-acl-28 policy DMZ there and that ACL allows all traffic. The policy-class sets where traffic can go to from the applied interface, so you want to limit the Public zone to those services on the DMZ that should be public.

Modify web-acl-28 as follows:

no permit ip any  any

permit tcp any host xx.xxx.xxx.90 eq 80

permit tcp any host xx.xxx.xxx.90 eq 443

permit tcp any host xx.xxx.xxx.91 eq 80

permit tcp any host xx.xxx.xxx.91 eq 443

...etc.

busy2
New Contributor

Re: Need assistance routing Public IP  natively w/o NAT

Thanks!!  Jay

We're up and running. 

busy2
New Contributor

Re: Need assistance routing Public IP  natively w/o NAT

One more quick question:

We want to subnet the inside 192.168.x.x network with a handful of 10.x.x.x /24 subnets on managed Cisco switches.

10.1.1.0, 10.1.2.0, 10.1.3.0

Should these (10.x.x.x) networks these be listed as secondary networks on the 192.168.x.x interface?

jayh
Honored Contributor
Honored Contributor

Re: Need assistance routing Public IP natively w/o NAT

busy2 wrote:

One more quick question:

We want to subnet the inside 192.168.x.x network with a handful of 10.x.x.x /24 subnets on managed Cisco switches.

10.1.1.0, 10.1.2.0, 10.1.3.0

Should these (10.x.x.x) networks these be listed as secondary networks on the 192.168.x.x interface?

You can, but it would be more scalable and flexible to create 802.1q subinterfaces on gigabit-eth 0/1 and create a trunk. Then split the networks by access VLANs on the Cisco switches. Something like:

interface gigabit-eth 0/1

  description trunk to LAN switches

  encapsulation 802.1q

!

interface gigabit-eth 0/1.101

  vlan-id 101

description [whatever]

ip access-policy Private

ip address 10.1.1.1 255.255.255.0

!

interface gigabit-eth 0/1.102

  vlan-id 102

description [whatever]

ip access-policy Private

ip address 10.1.2.1 255.255.255.0

!

interface gigabit-eth 0/1.103

  vlan-id 103

description [whatever]

ip access-policy Private

ip address 10.1.3.1 255.255.255.0

!

interface gigabit-eth 0/1.192

  vlan-id 192

  description Rushford

  ip address  192.168.10.1  255.255.255.0

  ip access-policy Private

  no rtp quality-monitoring

  media-gateway ip primary

  no awcp

  no shutdown

!

!

Then connect the Cisco switch to this as a trunk port and configure access ports on the Cisco switch for the VLANs 101, 102, 103, 192 to connect to the various inside LANs. You can create different access policies for each as needed. This gives you the logical equivalent of a different layer 3 routed port for each subnet.

busy2
New Contributor

Re: Need assistance routing Public IP  natively w/o NAT

Thanks for the tip.

Question:

Will devices on the various subnets be able to communicate with each other without policies?

or will they need to be provisioned in router - and/or  trunked in the switches to permit access

say printers are on the A network and computers are on the C network and bridges are on the B network. 

10.1.A.0 

10.1.B.0

10.1.C.0

jayh
Honored Contributor
Honored Contributor

Re: Need assistance routing Public IP natively w/o NAT

busy2 wrote:

Thanks for the tip.

Question:

Will devices on the various subnets be able to communicate with each other without policies?

Put them all in policy-class Private, then modify the Private class to include:

allow list web-acl-25 policy Private

They'll route through the TA900. If later you want to modify any of the policies it's much easier. Hosts on each subnet need to have their gateway configured to be the IP of that subinterface. You can also assign IPs by DHCP, just add the DHCP pools with appropriate networks.

busy2
New Contributor

Re: Need assistance routing Public IP  natively w/o NAT

Getting ready to make the move.

Since all of the LAN equipment across various links via bridges and managed cisco to cisco switch connections operate on the 192.x.x.0 network.  And I want to roll the vlan 101,102,103  subnets out without (stepping into it) & dropping connections in the process.

Does it make sense to set a trunk port for all of the 802.1q subinterfaces across all of the cisco switches first.

But to include in the trunk, the 192.168.x.x Lan as it is, on the main ge o/1 interface? -

And then begin to sort out the switch ports.

Or does it matter. Meaning I could also create the 192 Vlan subinterface for them as above and they will all come into the switch trunk port. And everything will stay up.  

Side note- Once this is completed, if I move printers to 10.x.1.0  will they be easily available to computers on the 10.x.2.0 subnet.   I believe you said yes it would work with web-acl-25 below

allow list web-acl-25 policy Private

jayh
Honored Contributor
Honored Contributor

Re: Need assistance routing Public IP natively w/o NAT

If you want to disturb the 192 subnet as little as possible, you can make it the native VLAN on the trunk. This means that you won't need to specify its tag on access interfaces. You'll still have some minimal downtime while configuring the trunk itself. To do this:

interface gigabit-eth 0/1.192

  vlan-id 192 native

However, I would take the time to tag it for consistency in troubleshooting later. This way all of the LAN subnets are configured the same way.

Yes, the printers and computers on different subnets will be able to communicate with each other. Because they're not in the same broadcast domain, you may need local DNS entries or to specify the printers by IP address, The Bonjour protocol which is often used to discover printers only works within a single broadcast domain.

busy2
New Contributor

Re: Need assistance routing Public IP  natively w/o NAT

Good point -

tagging and consistency across all interfaces looks like the way to go.

thnks