firebird-devel

[Firebird-devel] Firebird versus Firewalls once and for all

[Chris W. <chr...@ne...>]

Hi,

[When I say firewall, I really mean NAT gateway, but 'firewall' made for a
better subject]

I am struggling with a problem that many people seem to have had before:
accessing Firebird through a firewall when events are being used. I can't
understand why this problem hasn't been fixed earlier. I can only assume
that events are not widely used.

The problem is that the auxiliary connection created for the events doesn't
work causing lockup of both the client and server. Without a firewall the
way the communication protocol works is:

Client connects to server using TCP on port 3050
....
Events are registered
Client request auxialiary connection from server
Server reponds with port number and IP address to make auxiliary connection
to
Client connects to specified auxiliary IP address and port using TCP
...

This works fine on a LAN. If a straight firewall is used then an additional
port needs to be opened for the auxiliary connection. FB1.5 has an option to
make this port number a constant.

The problem is if address translation is used. The client makes the
auxiliary connection to the address and port specified by the server,
however this information was not translated by the NAT box so the IP address
is wrong. It will be the LAN address of the server, not the WAN address of
the NAT gateway which is what it should be.

I think that the fix is to have the client use the source IP address of the
auxiliary response packet, rather than the address from within the packet.
It looks like the fix needs to go into aux_connect() in inet.cpp. However I
can't work out how to get the source address of the packet from within this
function. The alternative would be to use the same server address as was
used for the main connection. If anyone has some pointers on how to do this,
or input on the fix, I would appreciate it.

Thanks,

Chris.

Re: [Firebird-devel] Firebird versus Firewalls once and for all

[Jim S. <ja...@ne...>]

Chris Waters wrote:

>The problem is that the auxiliary connection created for the events doesn't
>work causing lockup of both the client and server. Without a firewall the
>way the communication protocol works is:
>
>Client connects to server using TCP on port 3050
>....
>Events are registered
>Client request auxialiary connection from server
>Server reponds with port number and IP address to make auxiliary connection
>to
>Client connects to specified auxiliary IP address and port using TCP
>...
>
>The problem is if address translation is used. The client makes the
>auxiliary connection to the address and port specified by the server,
>however this information was not translated by the NAT box so the IP address
>is wrong. It will be the LAN address of the server, not the WAN address of
>the NAT gateway which is what it should be.
>
>  
>
The remote interface should retain the original IP address of the server 
and use just the port number it receives.  I don't know what I had in 
mind when I wrote the original code, but it's clearly wrong. 

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376

Re: [Firebird-devel] Firebird versus Firewalls once and for all

[Chris W. <ch...@wa...>]

Here is a patch while fixes this problem. When opening an auxiliary
connection it uses the same IP address as the existing connection, rather
than reading what the server reports us.

Regards,

Chris.

""Chris Waters"" <chr...@ne...> wrote in message
news:cdho1t$n48$1...@ne......
> Hi,
>
> [When I say firewall, I really mean NAT gateway, but 'firewall' made for a
> better subject]
>
> I am struggling with a problem that many people seem to have had before:
> accessing Firebird through a firewall when events are being used. I can't
> understand why this problem hasn't been fixed earlier. I can only assume
> that events are not widely used.
>
> The problem is that the auxiliary connection created for the events
doesn't
> work causing lockup of both the client and server. Without a firewall the
> way the communication protocol works is:
>
> Client connects to server using TCP on port 3050
> ....
> Events are registered
> Client request auxialiary connection from server
> Server reponds with port number and IP address to make auxiliary
connection
> to
> Client connects to specified auxiliary IP address and port using TCP
> ...
>
> This works fine on a LAN. If a straight firewall is used then an
additional
> port needs to be opened for the auxiliary connection. FB1.5 has an option
to
> make this port number a constant.
>
> The problem is if address translation is used. The client makes the
> auxiliary connection to the address and port specified by the server,
> however this information was not translated by the NAT box so the IP
address
> is wrong. It will be the LAN address of the server, not the WAN address of
> the NAT gateway which is what it should be.
>
> I think that the fix is to have the client use the source IP address of
the
> auxiliary response packet, rather than the address from within the packet.
> It looks like the fix needs to go into aux_connect() in inet.cpp. However
I
> can't work out how to get the source address of the packet from within
this
> function. The alternative would be to use the same server address as was
> used for the main connection. If anyone has some pointers on how to do
this,
> or input on the fix, I would appreciate it.
>
> Thanks,
>
> Chris.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
>


begin 666 firebird_nat_patch.dat
M+2TM(&EN970N8W!P+F]R9PDR,# T+3 W+3(W(#$W.C(S.C,Y+C P,# P,# P
M," M,#<P, HK*RL@:6YE="YC<' ),C P-"TP-RTR-R Q-SHQ.#HT-BXP,# P
M,# P,# @+3 W,# *0$ @+3$V,S$L,38@*S$V,S$L,S(@0$ *( H@"6EF("@H
M;B ]('-O8VME="A!1E])3D54+"!33T-+7U-44D5!32P@,"DI(#T]($E.5D%,
M241?4T]#2T54*2!["B )"6EN971?97)R;W(H<&]R="P@(G-O8VME="(L(&ES
M8U]N971?979E;G1?8V]N;F5C=%]E<G(L($524DY/*3L*( D)<F5T=7)N($Y5
M3$P["B )?0H@"BLO*@HK("H@3DI+("T@1&5T97)M:6YE(&%D9')E<W,@86YD
M('!O<G0@=&\@=7-E+@HK("H**R J(%1H92!A9&1R97-S(')E='5R;F5D(&)Y
M('1H92!S97)V97(@;6%Y(&)E(&EN8V]R<F5C="!I9B!I="!I<R!B96AI;F0@
M82!.050@8F]X"BL@*B!S;R!W92!M=7-T('5S92!T:&4@861D<F5S<R!T:&%T
M('=A<R!U<V5D('1O(&-O;FYE8W0@=&AE(&UA:6X@<V]C:V5T+"!N;W0@=&AE
M"BL@*B!A9&1R97-S(')E<&]R=&5D(&)Y('1H92!S97)V97(N"BL@*@HK("H@
M5&AE('!O<G0@;G5M8F5R(')E<&]R=&5D(&)Y('1H92!S97)V97(@:7,@=7-E
M9"X@1F]R($Y!5"!S=7!P;W)T('1H92!P;W)T(&YU;6)E<@HK("H@<VAO=6QD
M(&)E(&-O;F9I9W5R960@=&\@8F4@82!F:7AE9"!P;W)T(&YU;6)E<B!I;B!T
M:&4@<V5R=F5R(&-O;F9I9W5R871I;VXN"BL@*B\*( EI;F5T7WIE<F\H*%-#
M2$%2("HI("8@861D<F5S<RP@<VEZ96]F*&%D9')E<W,I*3L*+0EI;F5T7V-O
M<'DH<F5I;G1E<G!R971?8V%S=" \(&-H87(@*CXH<F5S<&]N<V4M/G!?<F5S
M<%]D871A+F-S=')?861D<F5S<RDL"BT)"0D@("A30TA!4B J*2 F(&%D9')E
M<W,L(')E<W!O;G-E+3YP7W)E<W!?9&%T82YC<W1R7VQE;F=T:"D["BL);" ]
M('-I>F5O9BAA9&1R97-S*3L**PES=&%T=7,@/2!G971P965R;F%M92@H4T]#
M2T54*2!P;W)T+3YP;W)T7VAA;F1L92P@*'-T<G5C="!S;V-K861D<B J*2 F
M861D<F5S<RP@)FPI.PHK"6EF("AS=&%T=7,@(3T@,"D@>PHK"0EI;F5T7V5R
M<F]R*'!O<G0L(")S;V-K970B+"!I<V-?;F5T7V5V96YT7V-O;FYE8W1?97)R
M+"!%4E).3RD["BL)"5-/0TQ/4T4H;BD["BL)"7)E='5R;B!.54Q,.PHK"7T*
M( EA9&1R97-S+G-I;E]F86UI;'D@/2!!1E])3D54.PHK"6%D9')E<W,N<VEN
M7W!O<G0@/2 H*'-T<G5C="!S;V-K861D<E]I;B J*2AR97-P;VYS92T^<%]R
M97-P7V1A=&$N8W-T<E]A9&1R97-S*2DM/G-I;E]P;W)T.PH@"B )5$A214%$
M7T58250["B )<W1A='5S(#T@8V]N;F5C="AN+" H<W1R=6-T('-O8VMA9&1R
M("HI("9A9&1R97-S+"!S:7IE;V8H861D<F5S<RDI.PH@"51(4D5!1%]%3E1%
94CL*( H@"6EF("AS=&%T=7,@/" P*2!["@``
`
end

Re: [Firebird-devel] Firebird versus Firewalls once and for all

[Dmitry Y. <di...@us...>]

"Chris Waters" <ch...@wa...> wrote:

> Here is a patch while fixes this problem. When opening an auxiliary
> connection it uses the same IP address as the existing connection, rather
> than reading what the server reports us.

Thanks for your help. I've just committed the patch into the HEAD branch.


Dmitry