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@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.
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@bandwidth.com] Sent: Tuesday, January 02, 2007 11:12 AM To: devel@openser.org; users@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@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.
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.
Could the "mhomed=1" option in the openser.cf fix this problem? I am more asking then answering, sorry about that. But I run a similar configuration without problems. Mind you I am not using ipsec.
The record-route will show two entries for this host, one for the incoming on eth1 and one for the out going on eth0.
just a thought.
ronw
Thanks!
mhomed=1 did the trick
Never knew about that one since I never needed it
T.R.
On 1/2/07 12:38 PM, "Ron Winacott" ronw@somanetworks.com wrote:
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.
Could the "mhomed=1" option in the openser.cf fix this problem? I am more asking then answering, sorry about that. But I run a similar configuration without problems. Mind you I am not using ipsec.
The record-route will show two entries for this host, one for the incoming on eth1 and one for the out going on eth0.
just a thought.
ronw
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@bandwidth.com] *Sent:* Tuesday, January 02, 2007 11:12 AM *To:* devel@openser.org; users@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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
-
Bogdan-Andrei Iancu -
Kasturi Narayanan -
Ron Winacott -
T.R. Missner