[Users] Multiple networks source address

T.R. Missner trmissner at bandwidth.com
Tue Jan 2 18:11:38 CET 2007


Hello,

I ran into a seemingly strange issue using openser to proxy an invite from
the public internet to a private ipsec tunnel on my network.

The problem appears to be caused by the fact that the packet is sent out to
on the correct interface ( eth1 in my case ) but still is using the source
address of et0 in the ip header.  This is causing my ipsec tunnel to ignore
the packet.

Is there anyway to control the source addr in the IP header?

Using a simple python script to send a upd packet across the same path I
have verified this is not a tunnel issue.

Example
et0: 4.X.X.229 packet arrives on this interface
eth1: 10.X.X.13 packet is sent out this interface

RURI is re-written and t_relay is used to send the packet to
destination: 10.X.X.115

Here is a partially redacted packet as captured by tethereal:

Frame 1 (982 bytes on wire, 982 bytes captured)
    Arrival Time: Jan  2, 2007 16:49:35.536412000
    [Time delta from previous packet: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Packet Length: 982 bytes
    Capture Length: 982 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:udp:sip:sdp]
Ethernet II, Src: DellComp_f6:27:19 (00:06:5b:f6:27:19), Dst:
DellComp_ec:8d:a3 (00:06:5b:ec:8d:a3)
    Destination: DellComp_ec:8d:a3 (00:06:5b:ec:8d:a3)
        Address: DellComp_ec:8d:a3 (00:06:5b:ec:8d:a3)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: DellComp_f6:27:19 (00:06:5b:f6:27:19)
        Address: DellComp_f6:27:19 (00:06:5b:f6:27:19)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 4.X.X.229 (4.X.X.229), Dst: 10.X.X.108 (10.X.X.108)
------> should source from 10.X.X.13 not 4.X.X.229
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
        0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 968
    Identification: 0x0076 (118)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x1dfe [correct]
        [Good: True]
        [Bad : False]
    Source: 4.X.X.229 (4.X.X.229)
    Destination: 10.X.X.108 (10.X.X.108)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 6060 (6060)
    Source port: 5060 (5060)
    Destination port: 6060 (6060)
    Length: 948
    Checksum: 0x1c67 [incorrect, should be 0x222a]
Session Initiation Protocol
    Request-Line: INVITE sip:+1720560XXXX at 10.X.X.108:6060 SIP/2.0
        Method: INVITE
        [Resent Packet: False]
    Message Header
        Record-Route: <sip:4.X.X.229;lr;ftag=as0473b81f>
        Via: SIP/2.0/UDP 4.X.X.229;branch=z9hG4bK7a42.e0b9bac5.0
            Transport: UDP
            Sent-by Address: 4.X.X.229



.....


Any clues on how to fix this problem?

Thanks,

T.R.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20070102/708fed88/attachment.htm 


More information about the Users mailing list