Route-MAP and NAT and 2 ISPs not working properly

Answered Question
Dec 4th, 2008

Hello,

I have a CISCO1841 with two Fa Interfaces (Fa0/1, Fa0/1/0) connecting to two different ISPs via dialer-Interfaces.

Another Interface is connected to LAN (Fa0/0) where all the clients are.Switchports are in VLAN22 which is a DMZ with a proxy server (SQID).

All Traffic from LAN is always directed to the proxy.

Requirement is now to route all HTTP Traffic via ISP2 and all other traffic (i.e. smtp) via ISP1.

After setting up the following config, WWW seems to work properly via the right interface, also SMTP traffic

is seen on the right interface. But when attempting to upload a file (i.e. attaching a file to mail at web.de) communicationg times

out with the error-message "zero sized reply" from the proxy-server. Doing the same without the proxy-server works perfect.

Could someone look at the config and provide some hints.

regards

HMK

Attachment: 
I have this problem too.
0 votes
Correct Answer by Laurent Aubert about 7 years 11 months ago

Actually, you have two ways to implement your routing policy:

1- Use PBR with the route-map DSL.

In this case you don't need the set interface in NATx route-map because PBR is already forwarding the right traffic to the right interface. Your default static routes are also useless and can be removed.

2- Use the NAT rules.

In this case you need the set interface in the NATx route-map. The same route-map will allow you to match the right traffic to NAT and to forward it to the right interface. The only condition is you first need to route your traffic to any interface configured with ip nat outside command to trigger the NAT. It is already the case with your default route (it could also be a fake loopback).

We have a separation between the outside interface which is the trigger for NAT and the actual interface on which the Nated traffic is sent.

PBR is not required in this case.

So it's up to you but I prefer the first one as it looks more familiar to understand.

Thanks

Laurent.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Giuseppe Larosa Thu, 12/04/2008 - 09:55

Hello Hubert,

you need to make some packets capture to understand what type of traffic is exchanged when using the email-client: may be when you try to open a file this triggers an ftp session but if so your client will use the other path and will try to present itself with a different IP source breaking the new TCP session setup.

Or you can open all TCP to specific hosts that are the mail servers so that if they open additional sockets they travel the same way as SMTP

Hope to help

Giuseppe

Hubert Mayr-Kne... Fri, 12/05/2008 - 08:07

Hello Guiseppe,

thanks for your response.

I did packet capture with a client not connected via the proxy just to see that this is pure HTML Traffic passing.

Open all TCP is not an option because the webmail server is just an example of non-working uploads. This happens also with various other sites. (i.e. DSL Speed Test sites where download and upload is measured: download works, upload breaks with the mentioned error)

regards

HMK

Giuseppe Larosa Fri, 12/05/2008 - 12:30

Hello Hubert,

I see that also ip inspect is configured on the DMZ interface.

There are also some access-lists applied to the interfaces.

For a complete analysis these should be examined.

I have some doubts about MTU settings: why they are different on the second ISP link is 1492.

On DMZ and primary link is 1451.

I would put 1451 also on the secondary link.

Hope to help

Giuseppe

Hubert Mayr-Kne... Mon, 12/08/2008 - 04:35

Hello Guiseppe,

you are right, this is a more complex configuration. I extracted the portions of interest. For the outgoing interfaces the configuration should be the same.

The MTU settings are the result of playing around. I will set them back to all the same size.

I'm just testing a configuration without the command "ip policy route-map DSL" but just with NAT route-maps.

-----------

ip route 0.0.0.0 0.0.0.0 Dialer0

ip route 0.0.0.0 0.0.0.0 Dialer1

route-map NAT_ADSL permit 10

match ip address 190

match interface Dialer1

!

no route-map NAT_SDSL

route-map NAT_SDSL permit 10

match ip address 191

match interface Dialer0

!

ip nat inside source route-map NAT_ADSL interface Dialer1 overload

ip nat inside source route-map NAT_SDSL interface Dialer0 overload

Do you think it will be more successful?

regards

HMK

Laurent Aubert Mon, 12/08/2008 - 05:47

Hi,

If I understand correctly, the traffic flow is always:

Clients --> Proxy ---> Internet (HTTP via Dialer 1 and SMTP via Dialer 0)

With your current configuration:

- All traffic is routed to Dialer 0 (Primary default route)

- Only SMTP traffic is Nated

You have a crypto-map applied to this interface. The config is missing so I don't know which traffic is encrypted but you should not translate this traffic !!

You also applied your PBR on the WAN interface. PBR checks only incoming traffic so it should be applied on Vlan22 interface instead. In this case the default routes are not necessary anymore.

ip tcp adjust-mss command is useful only on VLAN22 interface as only your proxy is allowed to reach the Internet. PPPoE add 8 Bytes of overhead so 1452 is the max MSS you can configured if you want to avoid fragmentation.

One last thing. You have many feature configured (NBAR, CBAC, ACL, MTU,..) so I suggest you to fall back to a simple config which allows you to validate your routing and once it's done, re-apply your security feature so you are sure on which one to focus if it stops working.

Thanks

Laurent.

Hubert Mayr-Kne... Mon, 12/08/2008 - 06:02

Hello Laurent,

thanks for your response.

The traffic flow is correct but in fact it should be HTTP/HTTPS via Dialer1 all other traffic via Dialer0.

You mentioned, only SMTP traffic is Nated? Why? I have an access-list 190 (permitting http) and an access-list 191 (permitting SMTP). Both are related to route-maps. What is wrong?

Crypto-Map is for incoming VPN-Clients. This config works already for a long time but will now be extended with a second interface to provide faster HTTP access.

If necessary I can provide the full config.

regards

HMK

Laurent Aubert Mon, 12/08/2008 - 06:27

Hi HMK,

The point is you don't have PBR on VLAN22, so the router will use its routing table to route the traffic received on VLAN22 interface.

As you have the following routes:

ip route 0.0.0.0 0.0.0.0 Dialer0

ip route 0.0.0.0 0.0.0.0 Dialer1 100

That makes me think everything is sent on Dialer0 interface

Now regarding the NAT rules, I made a mistake. You're right all the traffic will be translated but I think it's still sent to Dialer 0 even if your HTTP traffic is Nated with Dialer 1 interface IP address.

You should add a set interface dialer 1 to route-map NAT2. You can add a set interface dialer 0 on route-map NAT1 for consistency but it's useless while the default route to dialer 0 is configured.

This configuration will allow you to force the ouput interface:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080093fca.shtml#related

Thanks

Laurent.

Hubert Mayr-Kne... Mon, 12/08/2008 - 07:02

Hello,

just to summarize:

I will put the PBR statement (ip policy route-map DSL) only to VLAN22.

The route-maps will look like:

route-map DSL permit 10

match ip address 191

set interface Dialer0

set default interface Dialer0

route-map DSL permit 20

match ip address 190

set interface Dialer1

set default interface Dialer1

The NAT rules will look like:

route-map NAT1 permit 10

match ip address 191

set interfacee dialer0

route-map NAT2 permit 10

match ip address 190

set interfacee dialer1

-------

Now, to refer to my post at 4:35am PST

This config is much easier and smaller but is there any disadvantage?

Or can I use PBR on VLAN22 and the NAT route-maps? What will happen?

regards

HMK

Correct Answer
Laurent Aubert Mon, 12/08/2008 - 17:57

Actually, you have two ways to implement your routing policy:

1- Use PBR with the route-map DSL.

In this case you don't need the set interface in NATx route-map because PBR is already forwarding the right traffic to the right interface. Your default static routes are also useless and can be removed.

2- Use the NAT rules.

In this case you need the set interface in the NATx route-map. The same route-map will allow you to match the right traffic to NAT and to forward it to the right interface. The only condition is you first need to route your traffic to any interface configured with ip nat outside command to trigger the NAT. It is already the case with your default route (it could also be a fake loopback).

We have a separation between the outside interface which is the trigger for NAT and the actual interface on which the Nated traffic is sent.

PBR is not required in this case.

So it's up to you but I prefer the first one as it looks more familiar to understand.

Thanks

Laurent.

Actions

This Discussion