Multipath rule: how is considered proxied traffic?

Doesn't matter if you use Internal (Address) or External (Address) network definitions, both
resolve to "all local generated packets".

What you can do however for HTTP proxy traffic is to use Internal (Network) as Source IP
address or any other IP Address from your clients.

You can trust me, I implemented that feature [;)]

Cheers
 Ulrich

You can trust me, I implemented that feature [;)]

LOL [[:)]] Ok I cannot have anymore doubts about internal/external [[:)]]
The same behaviour occurs for each proxied service? I mean the services listed under Advanced - Allow Target Services (I suppose the answer is yes)

Thanks
eclipse79

Today I have added the second DSL line. Now I have to define the multipath rules but, before, I think I have to modify the existing masquerading / proxy settings. 

To summarize: I'd like to dedicate the primary DSL line for the connections that come from internet to our mail server and web server. The http traffic coming from our clients to internet should use the second DSL line. 

I ask for a confirmation from you [:)]
So I have to:
- modify existing masquerading rules, replacing all "External" entries with "External2" entries. 
- modify existing proxy rules, replacing all "External" entries with "External2" entries. 

is it right?

Thanks
eclipse79

EDIT: Ops, I just read that when you set uplink balancing, a new virtual network interface named Uplink Interfaces is automatically created. So I think I have to use it instead External1/External2 and use multipath to determine which interface I use for selected services/sources

In Masquerading, just change your existing rules to Uplink Interfaces.

Are both DSL lines "fast download, but slow upload"?  I would think you would want to do default balancing;  Web Surfing with persistence by Source/Destination and SMTP by Destination.  Remember, this is "Uplink Balancing" and not "Downlink Balancing". [;)]  If the links aren't the same speeds, adjust the weighting on the 'Uplink Balancing' tab.

Email is trickier than web; the outside web requests will come only to your first DSL if that's the only IP linked to the FQDN.

For SMTP, for the FQDN pointed to by your MX record, you'll want to add a second A record to public DNS with your new IP, change any applicable TXT record for SPF, and then have the new ISP add a reverse DNS entry for your new IP pointing to your MX record.  This will have the effect of load balancing incoming email.

If you don't want this load balancing effect, then you'll need to start by creating a new FQDN for your new IP, and then create a new MX record (with a higher number) pointing at it, similarly adjust any TXT (SPF) record and have the new ISP point a reverse DNS record at the new FQDN.

Cheers - Bob

Are both DSL lines "fast download, but slow upload"?  I would think you would want to do default balancing;  Web Surfing with persistence by Source/Destination and SMTP by Destination.  Remember, this is "Uplink Balancing" and not "Downlink Balancing". [;)]  If the links aren't the same speeds, adjust the weighting on the 'Uplink Balancing' tab.

Hi Bob. 
The first DSL line is an optic fiber, so 4down/4up. The second is asymmetric, 10down/1up.
Uhm... uplink and not downlink... so if I want to completely separate the line between client navigation (both downlink/uplink) and our web server  (from / to internet) I have to not use uplink balancing and multipath rules, but differentiate masquerading and proxy settings?

so if I want to completely separate the line between client navigation (both downlink/uplink) and our web server (from / to internet) I have to not use uplink balancing and multipath rules, but differentiate masquerading and proxy settings? 

You can use Uplink Balancing with Multipath rules or do it the "old" way in the Astaro - both will work s traffic initiated by the Astaro from an external interface will receive a response on that same interface.

Traffic initiated from somewhere else on the internet will be responded to by the Astaro from the interface on which the request arrived.  This means that you determine "response" traffic by the records in public DNS.

Cheers - Bob

You can use Uplink Balancing with Multipath rules or do it the "old" way in the Astaro - both will work s traffic initiated by the Astaro from an external interface will receive a response on that same interface.

bob, I think that there is something that I don't understand. 

Lets consider this example: a client (in LAN) has to download 100mb file from internet. 

If uplink balancing + multipath rules can manage only "upstream", I cannot set my ASG to use the second DSL using this method. But I can to with "old" style.

Traffic initiated from somewhere else on the internet will be responded to by the Astaro from the interface on which the request arrived.  This means that you determine "response" traffic by the records in public DNS.

Ok this is clear [:)]

If uplink balancing + multipath rules can manage only "upstream", I cannot set my ASG to use the second DSL using this method. But I can to with "old" style.

Yes, because if requests are sent from the second DSL, the responses will be returned to the second DSL.

What you can't do in any way in the Astaro is affect on which Astaro interface requests from the internet arrive - that only can be determined by public DNS.

Cheers - Bob

Yes, because if requests are sent from the second DSL, the responses will be returned to the second DSL.

What you can't do in any way in the Astaro is affect on which Astaro interface requests from the internet arrive - that only can be determined by public DNS.

Cheers - Bob

Oh, it's ok... I had this doubt because you underlined that we talk about uplink and not downlink, but now it's clear [:)] 
Thank you bob for your precious advices

Email is trickier than web; the outside web requests will come only to your first DSL if that's the only IP linked to the FQDN.

For SMTP, you'll want to add a second A record to public DNS with your new IP, change any applicable TXT record for SPF, and then have the new ISP add a reverse DNS entry for your new IP pointing to your MX record.  This will have the effect of load balancing incoming email.

If you don't want this load balancing effect, then you'll need to start by creating a new FQDN for your new IP, and then create a new MX record (with a higher number) pointing at it, similarly adjust any TXT (SPF) record and have the new ISP point a reverse DNS record at the new FQDN.

Bob, I now that it is partially OT, but I would be glad if you could clarify some questions about dns configuration for email server/ASG EMail configuration. I don't want load balancing effect but I need only a backup line for smtp. Currently we have:

A record: mail.mycompany.com
MX record: 10 mail.mycompany.com
A reverse DNS entry for MX record (so, ddd.ccc.bbb.aaa.in-addr.arpa mail.mycompany.com)
SPF record that allow only my ip to send emails

I should:
Add an A Record: mail2.mycompany.com
Add an entry to the MX record: 20 mail2.mycompany.com
Add a reverse DNS entry for MX record (so, ooo.nnn.mmm.lll-in-addr.arpa mail2.mycompany.com)
Configure SPF record in order to allow the second ip to send email.

The doubt, when the first line is broken:
1) Ok, the new entry in MX record (mail2.mycompany.com) will allow my ASG to receive mails (and forward them to my server) when the primary line is down. But the hostname in both my ASG and SMTP server is mail.mycompany.com (not mail2, and I think it's not possible to use a second hostname in ASG / SMTP server). Do you think that this situation will generate some issues in receiving email?

2) Considering that the hostname of both ASG and SMTP server is mail.mycompany.com and not mail2, the outgoing SMTP session will claim to be from mail.mycompany.com, but the source ip address will be the one that belongs to second dsl line. I think that in this case the remote SMTP will negate the delivey of emails (simply because the source hostname and its ip address does not match).

What do you think about?

Bye
eclipse79