12-04-2008 06:47 AM - edited 03-04-2019 12:36 AM
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
Solved! Go to Solution.
12-08-2008 05:57 PM
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.
12-04-2008 09:55 AM
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
12-05-2008 08:07 AM
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
12-05-2008 12:30 PM
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
12-08-2008 04:35 AM
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
12-08-2008 05:47 AM
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.
12-08-2008 06:02 AM
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
12-08-2008 06:27 AM
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.
12-08-2008 07:02 AM
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
12-08-2008 05:57 PM
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.
12-17-2008 06:23 AM
Thanks to Guiseppe and Laurent,
their input helped me solving my problem.
regards
HMK
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide