Hi all, need advice on OSPF and private vlans

[Ableton34]

Hi all.

I have a project to complete and need some help on the possible solution I can use.

Basically we have ospf area 0 and the users in question are in ospf area 7 and is a stub.

I need to route the traffic from these users out through area 0 through 3 core devices, onto an external firewall interface to be placed onto the vpn that sits on it. The firewall is not included in the ospf domain.

My thinking was that the firewall has a default route back into the ospf domain so dont need to worry about traffic coming in, however my job is to segregate these users and take them out of our core network and place them onto an external network via this vpn.

Not sure how to achieve this apart from static routing redistributed but surely this does not seperate their traffic only points the route to ospf?!

I was thinking I might have to use private vlans or policy routing but when I try policy routing the policy gets ignored due to normal forwarding.

Any help and advice would be greatly appreciated.

Cheers

Steve

[Ableton34]

Hi again.

So I have been playing with PBR and acl's, so far i have managed to create acl so that only the new subnet from the 3550 is allowed into the connected interface which is fine.

I have also created a pbr map to say that any matching the addressing of that subnet will have a next hop address of the adjacent 6513. However, i have created a new subnet on another interface on the 4507 and i can still reach it.

What I want to do is route all traffic from the subnet off the 3550 and direct it onto the 6513 without having access to any other network on any other interface on the 4507.

Debugging the pbr it is working ok but as I say I can still reach another network off the 4507, any ideas how I can force all traffic from the 3550 to only be allowed to the 6513?

Many thanks

Steve

[Jon Marshall]

Steve

So you have done all this on the 4500 ?

Can you post the config of what you have done and explain exactly where the config is applied it on which interfaces and also in terms of the acl which direction it is applied.

Also can you specify the source IP subnet and the destination IP subnet.

Jon

[Ableton34]

Hi Jon,

yes just on the 4507 at the moment, on the interface connected to the 3550

interface FastEthernet0/0

ip address 192.168.200.53 255.255.255.252

ip access-group 101 in

ip policy route-map DAT-Traffic

duplex auto

speed auto

access-list 101 permit ospf any any

access-list 101 permit ip 10.2.1.0 0.0.0.255 any

access-list 101 permit ip host 192.168.200.54 any

!

route-map DAT-Traffic permit 10

match ip address 101

set ip next-hop 192.168.42.5

[Jon Marshall]

So the source IPs are 10.2.1.x ?

And 192.168.42.5 is the next hop on the 6500 ?

Your acl is not really doing anything in terms of security as you are allowing 10.2.x.x to go anywhere. It is needed for the PBR though (if we actually need PBR - see below). We can also tighten up the acl so you would have a different acl for security and one for PBR but i need answers to the following -

1) The new subnet that you created on the 4500 that the 10.2.1.x clients can get to. Does the 6500 know about this subnet ? 

2) What is the destination subnet(s) that you want 10.2.1.x to be able to get to ie. presumably the subnet(s) at the other end of the VPN tunnel ?

3) These remote subnets. Is there a route to them in your core routing tables ?

If yes PBR may not be much use. If no then it might well be.

So can you provide answers to all the questions and we can go from there.

Jon

[Ableton34]

Hi Jon

1) yes the 6500 will know via ospf

2) at present i do not have that info, i have just made one up for testing on my rig. There is currently a static route set up as discussed earlier. 172.17.1.0 255.255.255.0 i think

3) Again yes as static route is being redistributed.

I guess this goes back to what we were talking about before, it is true we will not want the users on 3550 access to the core network and just to be routed direct to the firewall (vpn)

I suppose i just need to know how to get them over to the vpn without access to anything else without having to enter a deny access list on every interface on the 4507, which there are a lot going to different areas and with still using the core network to route them (ospf)

Cheers jon

[Jon Marshall]

Steve

1) I suspect PBR is sending the packets to the 6500 but because the 6500 has a route to that subnet it just routes it back. Obviously when you setup up PBR all the way this won't happen (see below though)

2)& 3). Okay but the question is will the actual networks be advertised into your network ie. apart from the area 7 users does anyone else need to get to these networks ?

If not then you need PBR. If those networks are to be added to your core then PBR is limited.

So if you are going to advertise the remote subnets into your core area then you only need an acl on the 4500 interface and that is pretty much it for outbound traffic. You would then control inbound traffic on the VPNN firewall ie. the only destination allowed coming in over the VPN is 10.2.1.x and presumably the 3550 address 192.168.200.254.  So rewriting the acls -

acl for PBR -

access-list   permit ip 10.2.1.0 0.0.0.255 any

access-list permit ip host 192.168.200.54 any

acl for the interface -

access-list permit ospf any any

access-list permit ip 10.2.1.0 0.0.0.255

access-list permit ip host 192.168.200.54

then depending on which numbers you used either reapply the acl to the interface or update your PBR config.

So the only remaiing question really is whether you need to add routes for the remote subnet(s) into your core area or whether to use PBR. I don't know what you are going to do about that. If you are then you do not need PBR.

I should point out that an acl on an interface is not really that secure and this is by no means segregation so you are still placing trust to an extent in the users and the remote support staff. You could, if this became an issue perhaps install a firewall between the users and the 4500 which would provide much more security but again that may not be an issue.

Jon

[Ableton34]

Hi Jon

i've had a chat to my boss and we definately need to just direct the traffic from the 3550 to the external subnet via the vpn.

Therefore I need to create an extended acl with policy routing so that it drops any packets that are not destined for the network 172.17.1.0 coming from 10.2.1.0. He thinks we may be able to do this with a combination of acl, policy routing and using the set default interface null0 to send any packets not destined to 172.17.1.0 get dropped. What do you think? is this possible? I dont really understand the null interface part.

Thanks

Steve

[Jon Marshall]

Steve

Don't know whether you got the last reply so retyping.

A null0 interface is used like this -

ip route 172.16.10.0 255.255.255.0 null0

a router receiving packets destined for this network would simply drop that packets. It would make sense on the 3550 although there are other ways to do it as well. Bear in mind with PBR, if the next hop is not available then the normal routing table is used. So a soluton may be to not run OSPF between the 3550 and the 4500 so the 3550 does not have routes to any part of your network.  Then you just add static routes for the remote network(s) that they are allowed access to.

I would still recommend using an acl on the 4500 interface that connects to the 3550 though because the 3550 is not going to be under your control so it is an additional layer of security, just in case there is a misconfiguration, for example on the 4500 and the 3550 ends up getting routes again.

PBR could then be used on the other devices to send the traffic to the firewall. You still haven't said whether the remote networks will actually be in your core routing tables. If they are then again PBR is of limited use. You could still use PBR to match the source traffic and send it to null0 if the destination is not the remote subnet but -

1) there are restrictions on which commands can be used on certain L3 switches and also whether the use of the command means the packets are software switched which can have a performance impact on the switch

2) if you only allow the remote subnet routes on the 3550 and have an acl on the 4500 to 3550 interface it is very unlikely you would actually see any traffic for other networks on your 4500/6500 etc.

That said if 2) is highly unlikely then you are probably not going to be face the issue in 1). Up to you really as to how many devices you want to configure and how much complexity you want.

Don't forget that you also need to account for the return path as connections can actually be initiated from the other end as well.

Jon

[Ableton34]

Hi again Jon.

Thanks for all your help on this, my task has become a bit more complicated. i have had success setting up policy routing from the 3550 over to the 6513. However i now have another issue. The 6513 is connected to the HP with layer 2 switching using port channels. So all traffic is going via vlans.

I presume I would just have to create a vlan interface to route the traffic via the port channel and onto the HP? I was doing really well until i came across this!! Nightmare! There are free gig interfaces on the 6513 but presume it would be easier to do a vlan?

Any advice as always greatly appreciated!

Steve

[Jon Marshall]

Steve

I'm not sure why you have to create a new L3 vlan interrace if the 6500 is already connected to the HP. Just use the one that is already there.

I'm assuming this is for the return traffic from the VPN box ie. you don't apply PBR to outgoing interfaces you apply it to incoming interfaces so -

1) from the 3550 to the HP switch you would use the interface on the 6500 that connects to the 4500

2) from the HP switch to the 3550 you would use the L3 vlan interface that is used to connect to the HP switch

On the 6500 you need to be careful with your PBR acls because the interfaces you apply it to may well have traffic for other users so make sure you only specify the source and destination subnets you actually want to policy route.

If i have misunderstood themn please clarify.

Jon

[Ableton34]

Hi again

I'll try and explain a bit better.

The physical interface between the 6513 and the HP is a trunked switchport using port channel. Then on the HP there is a physical trunked switchport to the firewall interface.

There is a vlan 363 which is labelled firewall inside.

Do i need to create a vlan interface on the 6513 then trunk that to the HP, trunk that vlan from HP to the firewall?

There is no policy routing that i can see at all on the HP, only ospf and static routes then the gig trunk port to the firewall.

Any ideas? I cannot reference a vlan as the next hop IP addres in my policy routing on the 4507 or the 6500 can I?

ive also noticed this on the 6500

interface Vlan363

description Vlan to N3

ip address 192.168.36.125 255.255.255.224

N3 being the core network that the vpn will go over

then on the HP end:

interface Vlan-interface363

ip address 192.168.36.126 255.255.255.224

Presumably then on the 4507 the next hop would be the vlan interface 363 on the hp?

Thanks

S

[Jon Marshall]

Steve

I have been asuming that the HP switch is L3 but it sounds from your description as though it might only be a L2 switch so the next hop from the 6513 would be the firewall.  If the 6500 has a trunk link and multiple L3 vlan interfaces for that link it sounds as though the 6500 is routing for vlans on the HP switch.

You need to confirm this one way or the other before we can proceed.

I don't think you will need to create a new L3 vlan interface, you should be able to use vlan 363 (if i am understanding correctly) but that will only be for return traffic from the firewall.

To clarify, for PBR you apply the route map to the incoming interface. For traffic from the 3550 to the firewall the L3 vlan interface connecting the 6500 to the firewall (via the HP switch) will never be the incoming interface. For return traffic from the firewall though it will be the incoming interface so you will need to apply a route map but i just want you to be clear as to what we are doing.

You can apply a route map to a L3 vlan interface just as you would a physical L3 interface.

So can you confirm whether or not the HP switch is a acting as a L2 or L3 switch ?

Jon

[Ableton34]

Hi, ive just updated the above with:

ive also noticed this on the 6500

interface Vlan363

description Vlan to N3

ip address 192.168.36.125 255.255.255.224

N3 being the core network that the vpn will go over

then on the HP end:

interface Vlan-interface363

ip address 192.168.36.126 255.255.255.224

Presumably then on the 4507 the next hop would be the vlan interface 363 on the hp?

As regards to L2 or 3 the HP has both switched interfaces and is using ospf

I am ok up to the point on the 6500 where i have policy routed to but then Im getting stuck

Cheers

S

thanks

S

[Jon Marshall]

Steve

Presumably then on the 4507 the next hop would be the vlan interface 363 on the hp?

So if i understand correctly the 192.168.36.96/27 network is used to connect the 6500 to the HP switch ?

If so you can do this, it is called a recursive next hop where the next hop is not directly connected ie. the 4500 has to send the traffic to the 6500 first and then the 6500 send it to the HP switch.  That will work as long as the 4500 has a route for the vlan 363 network. Then the 6500 would not need PBR config for the traffic from the 3550 to the firewall. To set a recursive next hop in the PBR route map you use -

set ip next-hop recursive

however you need to make sure it is supported by your 4500 and that it does not mean packets will be software switched so what IOS is your 4500 running ?

In addition it is important to note that you do lose some control as when it gets to the 6500 there is no PBR to explcitly tell it which next hop to use, it simply uses the routing table. This shouldn't matter as presumably the same next hop would be used whether it is from the routing table or from a PBR route map but it is something to be aware of.

That said it depends on how consistent you want your setup to be ie. traffic from the firewall to the 3550 cannot use PBR on the HP switch (or at least we don't know that it will, you could always look at the documentation). So the first place you can do PBR for the return traffic is the 6500 and assuming vlan 363 is used to connect the 6500 to the HP switch that would be the place to do it . So you may want to use PBR both ways on the 6500.

It really is up to you how you want to do this. As i have said quite a few times if the routing table would send the traffic the same way that your PBR is then you don't get a huge benefit from using PBR. More important are the acls on the interfaces and the routing table on the 3550.

Retrun traffic is harder because there is no device dedicated for area 7 users so you probably do need PBR at least to "force" traffic a certain way.

Again, that said, if the 3550 has a full routing table then PBR is of some use.

Jon

[Ableton34]

Hi Jon,

Ive just checked and there is a route on the 4500 to the network 192.168.36.96 which the interface of the firewall is on, here is my config so far on the 4500, presumably then I would not need any pbr on the 6500?

Interface g3/12

ip access-group 101 in

ip policy route-map DAT-Traffic

access-list 101 permit ip 192.168.208.128 0.0.0.63 any

access-list 101 permit ip 172.16.68.64 0.0.0.63 any

access-list 101 permit ip host 192.168.200.54 any

access-list 102 permit ip host 192.168.200.54 ………(address of external Subnet via vpn and wild card mask)

access-list 102 permit ip 192.168.208.128 0.0.0.63 ………(address of external subnet and wild card mask) any

route-map DAT-Traffic-out permit 10

match ip address 102

set ip next hop 192.168.36.97

route-map DAT-Traffic permit 20

set interface null0

What do you think?

Thanks

S