[Devel] RE: [Users] Multiple networks source address

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Jan 10 15:26:12 CET 2007


Hi Kasturi,

if the proto/ip/port is different (inbound versus outbound), openser 
will do double-routing - 2 RR hdrs will be added to define the inbound 
and outbound interfaces. This options is by default turned on. See :
http://www.openser.org/docs/modules/1.2.x/rr.html#AEN114

regards,
bogdan

Kasturi Narayanan wrote:

> Even if you come up with a mechanism to change the Source address it 
> does not solve the problem completely.
>
> The reason is “The IP address in the Record Route also needs to be 
> changed(manipulated) so that Subsequent Requests for the same call 
> coming from the other end of the Tunnel are routed correctly.
>
> Kasturi
>
> ------------------------------------------------------------------------
>
> *From:* T.R. Missner [mailto:trmissner at bandwidth.com]
> *Sent:* Tuesday, January 02, 2007 11:12 AM
> *To:* devel at openser.org; users at openser.org
> *Subject:* [Users] Multiple networks source address
>
> 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.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Devel mailing list
>Devel at openser.org
>http://openser.org/cgi-bin/mailman/listinfo/devel
>  
>





More information about the Users mailing list