[lvs-users] LVS-TUN with Debian and SIP

duane.larson at gmail.com duane.larson at gmail.com
Thu Dec 2 05:49:41 GMT 2010

i am trying to following the Rackspace.com guide to configuring LVS-TUN. I  
need to make sure the Real Servers respond back to the clients behind a NAT  
firewall with the the VIP that the Load Balancer is using. The client  
messages are making it to the load balancer and the load balancer is  
sending it to the real server without issue. The problem is that I am not  
sure the Real Server is sending the reply to the client with the VIP  
Spoofed IP address

So my IPs are like this
LoadBalancer eth0 - 173.XX61
LoadBalancer eth0:1 VIP - 173.XX164
RealServer eth0 - 173.XX252
RealServer tunl0 - 173.XX164

So when a remote client behind a firewall sends a SIP request I am seeing  
with tcpdump, i think, the request come from LoadBalancer eth0 interface to  
RealServer eth0 interface. And then the Real Server sends it to the client  
via the tunl0 interface. Here is the tcpdump

23:24:38.228857 IP (tos 0x20, ttl 49, id 0, offset 0, flags [DF], proto  
IPIP (4), length 786)
173.XX61 > 173.XX252: IP (tos 0x20, ttl 50, id 0, offset 0, flags [DF],  
proto UDP (17), length 766)
75.XX158.2048 > 173.XX164.5060: [udp sum ok] SIP, length: 738
REGISTER sip:ix.com SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK-6fcp0s56bhma;rport
From: "D2009" <sip:92009 at ix.com>;tag=bnguht24p3
To: "D2009" <sip:92009 at ix.com>
Call-ID: 3c26702745db-ecfnigcbzfn3
Max-Forwards: 70
<sip:92009 at;line=6ivfpyx6>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0b7f1294-57ad
User-Agent: snom360/8.4.18
Allow-Events: dialog
Supported: path, gruu
Expires: 3600
Content-Length: 0

23:24:38.229081 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP  
(17), length 535)
173.XX164.5060 > 75.XX158.2048: [bad udp cksum 3dc5!] SIP, length: 507
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP;branch=z9hG4bK-6fcp0s56bhma;rport=2048;received=75.XX158
From: "D2009" <sip:92009 at ix.com>;tag=bnguht24p3
To: "D2009" <sip:92009 at ix.com>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8fd8
Call-ID: 3c26702745db-ecfnigcbzfn3
WWW-Authenticate: Digest realm="ix.com",  
nonce="4cf72db47fbbx7f4500d30285732d8cd", qop="auth"
Server: OpenSIPS (1.6.3-notls (x86_64/linux))
Content-Length: 0

I am not sure if the (bad udp cksum) is what might be the issue.

Now when I do an ngrep capture on eth0 I see the following
Proxy01:/etc# ngrep -W byline -td eth0 . port 5060
interface: eth0 (173.xx0/
filter: (ip or ip6) and ( port 5060 )
match: .
U 2010/12/01 23:40:52.137349 173.xx164:5060 -> 75.xx158:62115
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP;branch=z9hG4bK-d8754z-3d9fd1cf6c0d8347-1---d8754z-;rport=62115;received=75.xx158.
To: "D"<sip:92009 at ix.com>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.55d1.
From: "D"<sip:92009 at irock.com>;tag=09eeeaa1.
WWW-Authenticate: Digest realm="ix.com",  
nonce="4cf7318298a31c6517039338fc54bf68c6538719", qop="auth".
Server: OpenSIPS (1.6.3-notls (x86_64/linux)).
Content-Length: 0.

This message would mean that the reply to the client is leaving the eth0  
interface since that is what I told ngrep to watch.

And then when I do an ngrep on the tunl0 interface I see the following
U 2010/12/01 23:44:10.862805 75.xx158:1077 -> 173.xx164:5060
REGISTER sip:ix.com SIP/2.0.
Via: SIP/2.0/UDP;branch=z9hG4bK-2ep5yxedv80v;rport.
From: "M" <sip:91612 at ix.com>;tag=otrgw6vs14.
To: "M" <sip:91612 at irock.com>.
Call-ID: 3c26702717a7-4569ut88v72t.
Max-Forwards: 70.
<sip:91612 at;line=ot3r8w1b>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:29aa32f7-ddd0-4c6e-8c7b-893729be895c>";audio;mobility="fixed";duplex="full";description="snom360";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO".
User-Agent: snom360/8.4.18.
Allow-Events: dialog.
Supported: path, gruu.
Expires: 3600.
Content-Length: 0.

This message tells me that the Load balancer sent me the message from the  
client to my tunl0 interface.

Is this all correct? I followed the guide from rackspace here
I did everything like they said except for the fact that my real server is  
Debian instead of CentoS

More information about the lvs-users mailing list