Hi, I have the my gateway with load balancing traffic going out over two providers. Web browsing is fine...working great. But, my clients (office staff) complains that MSN keeps disconnecting (in 5 mins). Why? Please help me... Regards, ro0ot
Just tell them that you have banned MSN B-) On 11/12/05, ro0ot <ro0ot@phreaker.net> wrote:> Hi, > > I have the my gateway with load balancing traffic going out over two > providers. Web browsing is fine...working great. > > But, my clients (office staff) complains that MSN keeps disconnecting > (in 5 mins). Why? > > Please help me... > > Regards, > ro0ot > > > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >
> I have the my gateway with load balancing traffic going out over two > providers. Web browsing is fine...working great. > > But, my clients (office staff) complains that MSN keeps disconnecting > (in 5 mins). Why?I''m not sure why but I have observed this behavior before. I seem to remember making a static route on the load balancer to make all traffic for the msn messaging servers go out a particular interface (not load balanced, but it really isn''t much traffic anyways). Not the best solution, but it works. X.X.X.X --> IP of msn server Y.Y.Y.Y --> IP of the gateway ip route add X.X.X.X/24 via Y.Y.Y.Y _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
ro0ot wrote:> Hi, > > I have the my gateway with load balancing traffic going out over two > providers. Web browsing is fine...working great. > > But, my clients (office staff) complains that MSN keeps disconnecting > (in 5 mins). Why?Do you mean MSN instant messenger? I''ve never used it, but I can give you a few generic steps to take when you want to figure out what''s going wrong with a connection. Are you familiar with tcpdump and/or ethereal? 1. Go to the computer of a client who is complaining about disconnection. 2. ssh into your gateway and run: # tcpdump -i eth0 host 123.123.123.123 and port not ssh Change "eth0" to the inside interface and "123.123.123.123" to the IP address of your client. 3. See if tcpdump is catching lots and lots of packets. If it is, either stop programs on your clients machine that access the Internet or use more filters (like "and port not imaps"). 4. Once you''re not catching lots of extraneous packets, kill tcpdump and run: # tcpdump -s 1500 -w log -i eth0 host 123.123.123.123 and port not ssh Include any other filters you have to use. 5. Have your client start up their program, and then sit there and wait. Don''t do anything else that would send packets through the gateway; you don''t want to clutter up the log. 6. See if the problem manifests. Most likely it won''t, because that''s just the way things are :) , but if it does you''ll have a log. Kill tcpdump and examine the file with: # tcpdump -r log If you want more verbosity, use "-v", "-vv", or "-vvv". Or, if you want to use a gui, copy the log file to some machine with X11 and use: # ethereal -r log -Corey
This problem is caused by the cached route to MSN expiring, and the kernel trying to route the existing connection over the other internet connection. If you''re doing SNAT, this will result in the source IP address changing, and MSN will reset the connection. On 11/12/05, Corey Hickey <bugfood-ml@fatooh.org> wrote:> ro0ot wrote: > > Hi, > > > > I have the my gateway with load balancing traffic going out over two > > providers. Web browsing is fine...working great. > > > > But, my clients (office staff) complains that MSN keeps disconnecting > > (in 5 mins). Why? > > Do you mean MSN instant messenger? I''ve never used it, but I can give > you a few generic steps to take when you want to figure out what''s going > wrong with a connection. Are you familiar with tcpdump and/or ethereal? > > 1. Go to the computer of a client who is complaining about disconnection. > > 2. ssh into your gateway and run: > # tcpdump -i eth0 host 123.123.123.123 and port not ssh > Change "eth0" to the inside interface and "123.123.123.123" to the IP > address of your client. > > 3. See if tcpdump is catching lots and lots of packets. If it is, either > stop programs on your clients machine that access the Internet or use > more filters (like "and port not imaps"). > > 4. Once you''re not catching lots of extraneous packets, kill tcpdump and > run: > # tcpdump -s 1500 -w log -i eth0 host 123.123.123.123 and port not ssh > Include any other filters you have to use. > > 5. Have your client start up their program, and then sit there and wait. > Don''t do anything else that would send packets through the gateway; you > don''t want to clutter up the log. > > 6. See if the problem manifests. Most likely it won''t, because that''s > just the way things are :) , but if it does you''ll have a log. Kill > tcpdump and examine the file with: > # tcpdump -r log > If you want more verbosity, use "-v", "-vv", or "-vvv". Or, if you want > to use a gui, copy the log file to some machine with X11 and use: > # ethereal -r log > > > -Corey > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >-- Ryan Castellucci http://ryanc.org/
Is it possible to increase the cached route timeout? Yes, I am using SNAT, will MASQUERADE help? Ryan Castellucci wrote:>This problem is caused by the cached route to MSN expiring, and the >kernel trying to route the existing connection over the other internet >connection. If you''re doing SNAT, this will result in the source IP >address changing, and MSN will reset the connection. > >On 11/12/05, Corey Hickey <bugfood-ml@fatooh.org> wrote: > > >>ro0ot wrote: >> >> >>>Hi, >>> >>>I have the my gateway with load balancing traffic going out over two >>>providers. Web browsing is fine...working great. >>> >>>But, my clients (office staff) complains that MSN keeps disconnecting >>>(in 5 mins). Why? >>> >>> >>Do you mean MSN instant messenger? I''ve never used it, but I can give >>you a few generic steps to take when you want to figure out what''s going >>wrong with a connection. Are you familiar with tcpdump and/or ethereal? >> >>1. Go to the computer of a client who is complaining about disconnection. >> >>2. ssh into your gateway and run: >># tcpdump -i eth0 host 123.123.123.123 and port not ssh >>Change "eth0" to the inside interface and "123.123.123.123" to the IP >>address of your client. >> >>3. See if tcpdump is catching lots and lots of packets. If it is, either >>stop programs on your clients machine that access the Internet or use >>more filters (like "and port not imaps"). >> >>4. Once you''re not catching lots of extraneous packets, kill tcpdump and >>run: >># tcpdump -s 1500 -w log -i eth0 host 123.123.123.123 and port not ssh >>Include any other filters you have to use. >> >>5. Have your client start up their program, and then sit there and wait. >>Don''t do anything else that would send packets through the gateway; you >>don''t want to clutter up the log. >> >>6. See if the problem manifests. Most likely it won''t, because that''s >>just the way things are :) , but if it does you''ll have a log. Kill >>tcpdump and examine the file with: >># tcpdump -r log >>If you want more verbosity, use "-v", "-vv", or "-vvv". Or, if you want >>to use a gui, copy the log file to some machine with X11 and use: >># ethereal -r log >> >> >>-Corey >>_______________________________________________ >>LARTC mailing list >>LARTC@mailman.ds9a.nl >>http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> >> >> > > >-- >Ryan Castellucci http://ryanc.org/ >_______________________________________________ >LARTC mailing list >LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > > >
I have this in /etc/iproute2/rt_tables as below: - 216 https.out 219 msn.out And, I have the below in my custom script: - $IPTABLES -t nat -A POSTROUTING -o eth3 -j SNAT --to-source 1.2.3.4 $IPTABLES -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 5.6.7.8 $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 443 -j MARK --set-mark 16 $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 1863 -j MARK --set-mark 19 ip rule add fwmark 16 table https.out ip rule add fwmark 19 table msn.out ip route add default via 1.2.3.4 dev eth3 table https.out ip route add default via 1.2.3.4 dev eth3 table msn.out But, still I am facing complaints... Edmundo Carmona wrote:>We have exaclty the same problem in our load-balancing proxy. > >Remember that if you are load-balancing, traffic eventually will come >out through another network interface,,, and hence, another source IP. > >The problem must be that the MSN service gets "confused" when he sees >that the one session has changed source IPs... or maybe it''s a IP >stack problem and not related to the MSN specifically. Anybody can >provide some more feedback on this? The IP session layer is supposed >to keep sessions across changing IPs? > >Our "solution" was to tell the MSN clients to use a proxy server that >has a single internet connection (separete from our main proxy server, >which is the one loadbalancing). > >On 11/13/05, ro0ot <ro0ot@phreaker.net> wrote: > > >>Hi, >> >>I have the my gateway with load balancing traffic going out over two >>providers. Web browsing is fine...working great. >> >>But, my clients (office staff) complains that MSN keeps disconnecting >>(in 5 mins). Why? >> >>Please help me... >> >>Regards, >>ro0ot >> >> >> >>_______________________________________________ >>LARTC mailing list >>LARTC@mailman.ds9a.nl >>http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> >> >> > > > > >
This is not a problem with linux it is a simple fact of IP/TCP and applications. A workaround is put the IP into a ipt_recent list then SNAT all that traffic the one way for a given time. There was a ipt_helper for MSN but I dont know where it is in development. I use the route taget in iptables rather than ip (sorry guys but you can just do so much funky stuff with it) So just to recap on my suggestion. Find the MSN traffic e.g. What ever port it uses for session initiation then put that ip into an ipt_recent list. The check that list before you snat. This will SNAT all the traffic from that IP to one interface for a certain amount of time that you set e.g. if it has not seen the packet within 600 secs clear it from the list. I use the for VoIP to multiple SNAT targets. On Mon, 2005-11-14 at 00:51 +0800, ro0ot wrote:> I have this in /etc/iproute2/rt_tables as below: - > > 216 https.out > 219 msn.out > > And, I have the below in my custom script: - > > $IPTABLES -t nat -A POSTROUTING -o eth3 -j SNAT --to-source 1.2.3.4 > $IPTABLES -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 5.6.7.8 > > $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 443 -j MARK > --set-mark 16 > $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 1863 -j MARK > --set-mark 19 > > ip rule add fwmark 16 table https.out > ip rule add fwmark 19 table msn.out > > ip route add default via 1.2.3.4 dev eth3 table https.out > ip route add default via 1.2.3.4 dev eth3 table msn.out > > But, still I am facing complaints... > > Edmundo Carmona wrote: > > >We have exaclty the same problem in our load-balancing proxy. > > > >Remember that if you are load-balancing, traffic eventually will come > >out through another network interface,,, and hence, another source IP. > > > >The problem must be that the MSN service gets "confused" when he sees > >that the one session has changed source IPs... or maybe it''s a IP > >stack problem and not related to the MSN specifically. Anybody can > >provide some more feedback on this? The IP session layer is supposed > >to keep sessions across changing IPs? > > > >Our "solution" was to tell the MSN clients to use a proxy server that > >has a single internet connection (separete from our main proxy server, > >which is the one loadbalancing). > > > >On 11/13/05, ro0ot <ro0ot@phreaker.net> wrote: > > > > > >>Hi, > >> > >>I have the my gateway with load balancing traffic going out over two > >>providers. Web browsing is fine...working great. > >> > >>But, my clients (office staff) complains that MSN keeps disconnecting > >>(in 5 mins). Why? > >> > >>Please help me... > >> > >>Regards, > >>ro0ot > >> > >> > >> > >>_______________________________________________ > >>LARTC mailing list > >>LARTC@mailman.ds9a.nl > >>http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > >> > >> > >> > > > > > > > > > > > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
I had similiar problems, re-reading the docs seemed to solved my problem, when u create your routing tables, u must make sure, the packet is returning on the same interface, cause what I found happens, that after the caching expired, all my downloads use to break, including msn this is an example of one interface''s routing table, now for each interface do the same , then setup your default global scope $ip route add 10.0.1.0/24 dev eth2 src 10.0.1.50 table line1 $ip route add default via 10.0.1.19 table line1 $ip rule add from 10.0.1.50 table line1 $ip route add 10.0.2.0/24 dev eth3 src 10.0.2.50 table line2 $ip route add default via 10.0.2.19 table line2 $ip rule add from 10.0.2.50 table line2 hope this helps J ro0ot wrote:> I have this in /etc/iproute2/rt_tables as below: - > > 216 https.out > 219 msn.out > > And, I have the below in my custom script: - > > $IPTABLES -t nat -A POSTROUTING -o eth3 -j SNAT --to-source 1.2.3.4 > $IPTABLES -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 5.6.7.8 > > $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 443 -j MARK > --set-mark 16 > $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 1863 -j MARK > --set-mark 19 > > ip rule add fwmark 16 table https.out > ip rule add fwmark 19 table msn.out > > ip route add default via 1.2.3.4 dev eth3 table https.out > ip route add default via 1.2.3.4 dev eth3 table msn.out > > But, still I am facing complaints... > > > Edmundo Carmona wrote: > >> We have exaclty the same problem in our load-balancing proxy. >> >> Remember that if you are load-balancing, traffic eventually will come >> out through another network interface,,, and hence, another source IP. >> >> The problem must be that the MSN service gets "confused" when he sees >> that the one session has changed source IPs... or maybe it''s a IP >> stack problem and not related to the MSN specifically. Anybody can >> provide some more feedback on this? The IP session layer is supposed >> to keep sessions across changing IPs? >> >> Our "solution" was to tell the MSN clients to use a proxy server that >> has a single internet connection (separete from our main proxy server, >> which is the one loadbalancing). >> >> On 11/13/05, ro0ot <ro0ot@phreaker.net> wrote: >> >> >>> Hi, >>> >>> I have the my gateway with load balancing traffic going out over two >>> providers. Web browsing is fine...working great. >>> >>> But, my clients (office staff) complains that MSN keeps disconnecting >>> (in 5 mins). Why? >>> >>> Please help me... >>> >>> Regards, >>> ro0ot >>> >>> >>> >>> _______________________________________________ >>> LARTC mailing list >>> LARTC@mailman.ds9a.nl >>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>> >>> >> >> >> >> >> >> > > > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- /*---------------------------------------------------------------------*/ __ _ ---------- / / (_)__ __ ____ __ --------- ------- / /__/ / _ \/ // /\ \/ / -------- ---- /____/_/_//_/\_,_/ /_/\_\ ------ localhost@localdomain.za.net
I have the similar line below but it doesn''t help, :( ip route add 1.2.3.0/24 dev eth3 src 1.2.3.4 table 2 ip route add default via 1.2.3.3 table 2 ip rule add from 1.2.3.4 table 2 ip route add 5.6.7.0/24 dev eth4 src 5.6.7.8 table 3 ip route add default via 5.6.7.7 table 3 ip rule add from 5.6.7.8 table 3 Jandre Olivier wrote:> I had similiar problems, re-reading the docs seemed to solved my > problem, when u create your routing tables, u must make sure, the > packet is returning on the same interface, cause what I found happens, > that after the caching expired, all my downloads use to break, > including msn > > this is an example of one interface''s routing table, now for each > interface do the same , then setup your default global scope > > $ip route add 10.0.1.0/24 dev eth2 src 10.0.1.50 table line1 > $ip route add default via 10.0.1.19 table line1 > $ip rule add from 10.0.1.50 table line1 > > $ip route add 10.0.2.0/24 dev eth3 src 10.0.2.50 table line2 > $ip route add default via 10.0.2.19 table line2 > $ip rule add from 10.0.2.50 table line2 > > hope this helps > > J > > > > ro0ot wrote: > >> I have this in /etc/iproute2/rt_tables as below: - >> >> 216 https.out >> 219 msn.out >> >> And, I have the below in my custom script: - >> >> $IPTABLES -t nat -A POSTROUTING -o eth3 -j SNAT --to-source 1.2.3.4 >> $IPTABLES -t nat -A POSTROUTING -o eth4 -j SNAT --to-source 5.6.7.8 >> >> $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 443 -j MARK >> --set-mark 16 >> $IPTABLES -t mangle -A PREROUTING -i eth1 -p tcp --dport 1863 -j MARK >> --set-mark 19 >> >> ip rule add fwmark 16 table https.out >> ip rule add fwmark 19 table msn.out >> >> ip route add default via 1.2.3.4 dev eth3 table https.out >> ip route add default via 1.2.3.4 dev eth3 table msn.out >> >> But, still I am facing complaints... >> >> >> Edmundo Carmona wrote: >> >>> We have exaclty the same problem in our load-balancing proxy. >>> >>> Remember that if you are load-balancing, traffic eventually will come >>> out through another network interface,,, and hence, another source IP. >>> >>> The problem must be that the MSN service gets "confused" when he sees >>> that the one session has changed source IPs... or maybe it''s a IP >>> stack problem and not related to the MSN specifically. Anybody can >>> provide some more feedback on this? The IP session layer is supposed >>> to keep sessions across changing IPs? >>> >>> Our "solution" was to tell the MSN clients to use a proxy server that >>> has a single internet connection (separete from our main proxy server, >>> which is the one loadbalancing). >>> >>> On 11/13/05, ro0ot <ro0ot@phreaker.net> wrote: >>> >>> >>>> Hi, >>>> >>>> I have the my gateway with load balancing traffic going out over two >>>> providers. Web browsing is fine...working great. >>>> >>>> But, my clients (office staff) complains that MSN keeps disconnecting >>>> (in 5 mins). Why? >>>> >>>> Please help me... >>>> >>>> Regards, >>>> ro0ot >>>> >>>> >>>> >>>> _______________________________________________ >>>> LARTC mailing list >>>> LARTC@mailman.ds9a.nl >>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> _______________________________________________ >> LARTC mailing list >> LARTC@mailman.ds9a.nl >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > >