Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 3319 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Policy Based Routing in V7.001 impossible? [using 2 dsl connections]

philippg
Hello folks,

last night we set up a as 7.001 to change our old asl6 system. everything worked fine exlcluding policy based routing. 
ife looked aroudn the hole forum, but i cant find any kind of solution only same probs:

- http://astaro.org/showthread.php?t=17959
- http://astaro.org/showthread.php?t=17811
- and so on

neither the knowledgebase cant help us.
- http://portal.knowledgebase.net/display/2n/kb/article.asp?aid=236926

what we want to do:

All traffic is sent to ASL 7.001. Only HTTP, HTTPS and FTP traffic should be seperated moved over out ADSL connection. Remaining traffic should be switched via SDSL into the internet. with asl v6 every think works fine. all policies and settings from asl v6 are migrated manually 1:1 to asl v7
here what weve done last night:

were using 2 dsl connection
- External_SDSL -> eht1 [Standard GW -> pppoe]
- External_ADSL -> eth2 [192.168.2.*** -> ADSL Router]
- DMZ              -> eth0 [10.10.0.*** -> DMZ/LAN]

then we set up the ADSL_Router Objekt like this one:

- ROUTER_ADSL 192.168.2.***

After this we created three new policy based rules like:

- First One:
Route Type: Gateway router
Source Interface: >
Source Network: DMZ
Service: FTP
Destination Network: ANY
Gateway:ADSL_Router

- Second:
Route Type: Gateway router
Source Interface: >
Source Network: DMZ
Service: HTTP
Destination Network: ANY
Gateway:ADSL_Router

- Third:
- First One:
Route Type: Gateway router
Source Interface: >
Source Network: DMZ
Service: HTTPS
Destination Network: ANY
Gateway:ADSL_Router

Then weve set up a Masq:

- DMZ (Network) External_SDSL
- DMZ (Network) External_ADSL

And tata. nothing was working. no http, no http neither ftp. after disabling our 3 policies we can surf. but while having a look aht whatismyip.com weve seen, that were surfing over SDSL. And that should not really be possible.

what hapend with v7.001? did we set up sth wrong. is policy based routing still possible? were no out of ideas, maybe you can give us a helpfully hint.

best thanks for reading and king regards

Philipp


This thread was automatically locked due to age.
  • 0 in reply to hobycat
    Well, one of the mentioned post is from me. 

    I have spent a lot of time to get a working configuration. 
    Now I can say, It is not a configuration issue. 

    Policy based routing is simply not working correctly in v7.00x and nobody takes care of it.

    If you configure your system according the knowledgebase, then just take a look at a tcpdump. The NAT/MASQ is not working correctly.

    I anybody wants to know more, I can post my logs.
  • 0
    This is a tcpdump of simple ping command using the standard gateway.
    The ping is working. 

    16:10:47.456633 IP astaro.zuhause.xx > gv-in-f104.google.com: ICMP echo request, id 512, seq 7168, length 40

    16:10:47.510050 IP gv-in-f104.google.com > astaro.zuhause.xx: ICMP echo reply, id 512, seq 7168, length 40

    16:10:48.472382 IP astaro.zuhause.xx > gv-in-f104.google.com: ICMP echo request, id 512, seq 7424, length 40

    16:10:48.526090 IP gv-in-f104.google.com > astaro.zuhause.xx: ICMP echo reply, id 512, seq 7424, length 40


    This is a tcpdump of a simple ping command, with a enabled policy based route, 
    using my "alternative" gateway. This ping is NOT working. 


    16:22:39.971185 IP astaro.zuhause.xx > gv-in-f104.google.com: ICMP echo request, id 512, seq 37632, length 40

    16:22:40.075432 IP gv-in-f104.google.com > astaro.zuhause.xx: ICMP echo reply, id 512, seq 37632, length 40

    16:22:40.075977 IP gv-in-f104.google.com > 192.168.2.52: ICMP echo reply, id 512, seq 37632, length 40

    16:22:44.978278 IP astaro.zuhause.xx > gv-in-f104.google.com: ICMP echo request, id 512, seq 37888, length 40

    16:22:45.084924 IP gv-in-f104.google.com > astaro.zuhause.xx: ICMP echo reply, id 512, seq 37888, length 40

    16:22:45.085480 IP gv-in-f104.google.com > 192.168.2.52: ICMP echo reply, id 512, seq 37888, length 40



    Imho there is a problem with the NAT/MASQ mechanism.
    The ping is in both examples executed on 192.168.2.52, pointing to google.de
  • 0 in reply to Agadoo
    I have the same problem, i tried different configuration of snat/policy routing but no way.

    here is a tcpdump from the firewall:

    astaro:/root # tcpdump -v -i eth2 port 80 
    tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
    10:44:57.031154 IP (tos 0x0, ttl 126, id 40877, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.1.200.2189 > f1.www.vip.re3.yahoo.com.http: S, cksum 0xc6e1 (correct), 571152200:571152200(0) win 65535 
    10:44:57.212143 IP (tos 0x0, ttl  46, id 32886, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 192.168.1.200.2189: S, cksum 0x9d7b (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:44:57.212528 IP (tos 0x0, ttl  45, id 32886, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 172.16.5.70.2189: S, cksum 0xae95 (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:00.080650 IP (tos 0x0, ttl 126, id 40890, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.1.200.2189 > f1.www.vip.re3.yahoo.com.http: S, cksum 0xc6e1 (correct), 571152200:571152200(0) win 65535 
    10:45:00.211991 IP (tos 0x0, ttl  46, id 38823, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 192.168.1.200.2189: S, cksum 0x9d7b (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:00.212247 IP (tos 0x0, ttl  45, id 38823, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 172.16.5.70.2189: S, cksum 0xae95 (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:00.260113 IP (tos 0x0, ttl  46, id 38901, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 192.168.1.200.2189: S, cksum 0x9d7b (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:00.260423 IP (tos 0x0, ttl  45, id 38901, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 172.16.5.70.2189: S, cksum 0xae95 (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:06.096454 IP (tos 0x0, ttl 126, id 40907, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.1.200.2189 > f1.www.vip.re3.yahoo.com.http: S, cksum 0xc6e1 (correct), 571152200:571152200(0) win 65535 
    10:45:06.259624 IP (tos 0x0, ttl  46, id 51296, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 192.168.1.200.2189: S, cksum 0x9d7b (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:06.259975 IP (tos 0x0, ttl  45, id 51296, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 172.16.5.70.2189: S, cksum 0xae95 (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:06.275626 IP (tos 0x0, ttl  46, id 51354, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 192.168.1.200.2189: S, cksum 0x9d7b (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:06.275970 IP (tos 0x0, ttl  45, id 51354, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 172.16.5.70.2189: S, cksum 0xae95 (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:18.276971 IP (tos 0x0, ttl  46, id 9221, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 192.168.1.200.2189: S, cksum 0x9d7b (correct), 869856693:869856693(0) ack 571152201 win 65535 
    10:45:18.277213 IP (tos 0x0, ttl  45, id 9221, offset 0, flags [DF], proto: TCP (6), length: 48) f1.www.vip.re3.yahoo.com.http > 172.16.5.70.2189: S, cksum 0xae95 (correct), 869856693:869856693(0) ack 571152201 win 65535 

    15 packets captured
    30 packets received by filter
    0 packets dropped by kernel
    astaro:/root #


    I think it's probably a bug in 7.002!!?

    Regards,
  • 0 in reply to jaouhari
    I agreee, 

    it is a bug. 
    But this problem has not been listed in the KIT.
  • 0 in reply to Agadoo
    What i see in the Live Log: Packet Filter
    1) i have the allowed requests
    2) i have an other line: the response from the visited sites are dropped.
     
    what's wrong?
     
    Regards,
  • 0 in reply to jaouhari
    Policy based routing is broken in Astaro 7.002.  We have a commercial license, and the existing KB article on how to set it up was a result of some playing a support rep & I did.

    It was working for a while configured as listed in the KB, but then it stopped working.

    Their current response is that it's a bug, and the fix is supposed to be released in 7.003 or 7.004.
  • 0
    The Bug has been fixed in 7.003.