Subject | Re: Events and Firewall again (long post) |
---|---|
Author | mikcaau |
Post date | 2005-08-15T23:01:20Z |
--- In firebird-support@yahoogroups.com, "fabiano_bonin"
<fabiano@p...> wrote:
Here it is:
The reason we use TCP is because it is so versatile.
Let me first discuss a simple setup,
where many clients attaching to one Firebird database on a LAN.
I will look at only one client at address $Client
connecting to database at $Server.
Event port has been set at the server (in firebird.conf) to
$RemoteAuxPort and the Firebird server has been restarted.
Client attempt to connect and sends a TCP packet like
DestAddr = $Server
SourceAddr = $Client
DestPort = $GdsDb
SourcePort = $ClientDataPort
Server receives the packet and replies with a TCP packet like
DestAddr = $Client
SourceAddr = $Server
SourcePort = $ServerPort
DestPort = $ClientSourcePort
in the data part of the packet is $RemoteAuxPort, client (I think need
ethereal to check) establishes a connection to server with TCP packet like
DestAddr = $Server
SourceAddr = $Client
DestPort = $RemoteAuxPort,
SourcePort = $ClientEventPort
Firebird notes source address and source port and sends events to
DestAddr = $Client
SourceAddr = $Server
SourcePort = $RemoteAuxPort
DestPort = $ClientEventPort
I might be readin this incorrectly as for this Server and Client are
the same machine and netstat gives me this
Active Connections
Proto Local Address Foreign Address State
TCP ppower:32000 PPOWER:1232 ESTABLISHED
TCP ppower:1218 PPOWER:gds_db ESTABLISHED
TCP ppower:1232 PPOWER:32000 ESTABLISHED
TCP ppower:gds_db PPOWER:1218 ESTABLISHED
Note that the connections are established so that a firewall that
allows established connections to continue will have no problems with
these.
Now lets put NAT into the equation.
For this part of the diatribe the FbServer is behind a NAT server
which relays connections from multiple clients.
The NAT router has external address $NatExternal and has internal
address $NatInternal and forwards everything to $Server.
Client attempt to connect to server by sending
DestAddr = $NatExternal
SourceAddr = $Client
DestPort = $GdsDb
SourcePort = $ClientDataPort
Nat receives this packet and does the following
Finds first available port $NatClientDataPort
writes an entry in its Nat (mangle) table like
$NatClientDataPort
sender = $Client
SourcePort = $ClientDataPort
modifies the incoming packet to
DestAddr = $Server
SourceAddr = $NatInternal
DestPort = $GdsDb
SourcePort = $NatClientDataPort
and forwards it to FbServer.
FbServer responds and sends a packet like
DestAddr = $NatInternal
SourceAddr = $Server
DestPort = $NatClientDataPort
SourcePort = $GdsDb
Nat takes this packet, looks up reference $NatClientDataPort in its
mangle table,
modifies it to
DestAddr = $Client
SourceAddr = $NatExternal
DestPort = $ClientDataPort
SourcePort = $GdsDb
It then sends this packet ot into the wild wild world.
Nat also notices that this connection is Established and adds that
state to its mangle table.
in the data part of the packet is $RemoteAuxPort, client (I think need
ethereal to check) establishes a connection to server with TCP packet like
so client attempts to establish a connection to server at that port
It sends a TCP packet like
DestAddr = $NatExternal
SourceAddr = $Client
DestPort = $RemoteAuxPort,
SourcePort = $ClientEventPort
Finds first available port $NatClientEventPort
writes an entry in its Nat (mangle) table like
$NatClientEventPort
sender = $Client
SourcePort = $ClientEventPort
modifies the incoming packet to
DestAddr = $Server
SourceAddr = $NatInternal
DestPort = $RemoteAuxPort
SourcePort = $NatClientEventPort
and forwards it to FbServer.
FbServer responds and sends a packet like
DestAddr = $NatInternal
SourceAddr = $Server
DestPort = $NatClientEventPort
SourcePort = $RemoteAuxPort,
Nat receives this packet and looks up its mangle table and converts
the packet to
DestAddr = $Client
SourceAddr = $NatExternal
DestPort = $ClientEventPort
SourcePort = $RemoteAuxPort,
Nat also notes that this connection is established and records this
information in its mangle table.
From the above it is clear that Firebird events will traverse Nat.
It is also clear that FbServer.Firewall must allow traffic in both
directions on $RemoteAuxPort as must clients (otherwise connection
won't be established).
The client end of the connection can also be NATted with the same NAT
magic happening there. I don't propose to enumerate that end because
it just a mirror of the example given.
Caveats: I'm not sure which object (Client or Server) establishes the
event path.
The above is simplified so I could get my head around it.
I might have it completely wrong - I'm sure that someone will let me know.
Conclusion:
Firebird data and events can traverse NAT and firewalls if they are
configured to suit.
Firebird events are just data channels it is the dll or library that
reacts differently.
In effect the differences between Data connections and event
connections are
1) They use a different port
2) Events are handled by the library which then calls the client
application
3) Events are asynchonous.
Mick Arundell
<fabiano@p...> wrote:
> > Best regards,Last night I went inside to feed the pets then I felt a soapbox coming on.
> > Pavel Menshchikov
> > http://www.ls-software.com
Here it is:
The reason we use TCP is because it is so versatile.
Let me first discuss a simple setup,
where many clients attaching to one Firebird database on a LAN.
I will look at only one client at address $Client
connecting to database at $Server.
Event port has been set at the server (in firebird.conf) to
$RemoteAuxPort and the Firebird server has been restarted.
Client attempt to connect and sends a TCP packet like
DestAddr = $Server
SourceAddr = $Client
DestPort = $GdsDb
SourcePort = $ClientDataPort
Server receives the packet and replies with a TCP packet like
DestAddr = $Client
SourceAddr = $Server
SourcePort = $ServerPort
DestPort = $ClientSourcePort
in the data part of the packet is $RemoteAuxPort, client (I think need
ethereal to check) establishes a connection to server with TCP packet like
DestAddr = $Server
SourceAddr = $Client
DestPort = $RemoteAuxPort,
SourcePort = $ClientEventPort
Firebird notes source address and source port and sends events to
DestAddr = $Client
SourceAddr = $Server
SourcePort = $RemoteAuxPort
DestPort = $ClientEventPort
I might be readin this incorrectly as for this Server and Client are
the same machine and netstat gives me this
Active Connections
Proto Local Address Foreign Address State
TCP ppower:32000 PPOWER:1232 ESTABLISHED
TCP ppower:1218 PPOWER:gds_db ESTABLISHED
TCP ppower:1232 PPOWER:32000 ESTABLISHED
TCP ppower:gds_db PPOWER:1218 ESTABLISHED
Note that the connections are established so that a firewall that
allows established connections to continue will have no problems with
these.
Now lets put NAT into the equation.
For this part of the diatribe the FbServer is behind a NAT server
which relays connections from multiple clients.
The NAT router has external address $NatExternal and has internal
address $NatInternal and forwards everything to $Server.
Client attempt to connect to server by sending
DestAddr = $NatExternal
SourceAddr = $Client
DestPort = $GdsDb
SourcePort = $ClientDataPort
Nat receives this packet and does the following
Finds first available port $NatClientDataPort
writes an entry in its Nat (mangle) table like
$NatClientDataPort
sender = $Client
SourcePort = $ClientDataPort
modifies the incoming packet to
DestAddr = $Server
SourceAddr = $NatInternal
DestPort = $GdsDb
SourcePort = $NatClientDataPort
and forwards it to FbServer.
FbServer responds and sends a packet like
DestAddr = $NatInternal
SourceAddr = $Server
DestPort = $NatClientDataPort
SourcePort = $GdsDb
Nat takes this packet, looks up reference $NatClientDataPort in its
mangle table,
modifies it to
DestAddr = $Client
SourceAddr = $NatExternal
DestPort = $ClientDataPort
SourcePort = $GdsDb
It then sends this packet ot into the wild wild world.
Nat also notices that this connection is Established and adds that
state to its mangle table.
in the data part of the packet is $RemoteAuxPort, client (I think need
ethereal to check) establishes a connection to server with TCP packet like
so client attempts to establish a connection to server at that port
It sends a TCP packet like
DestAddr = $NatExternal
SourceAddr = $Client
DestPort = $RemoteAuxPort,
SourcePort = $ClientEventPort
Finds first available port $NatClientEventPort
writes an entry in its Nat (mangle) table like
$NatClientEventPort
sender = $Client
SourcePort = $ClientEventPort
modifies the incoming packet to
DestAddr = $Server
SourceAddr = $NatInternal
DestPort = $RemoteAuxPort
SourcePort = $NatClientEventPort
and forwards it to FbServer.
FbServer responds and sends a packet like
DestAddr = $NatInternal
SourceAddr = $Server
DestPort = $NatClientEventPort
SourcePort = $RemoteAuxPort,
Nat receives this packet and looks up its mangle table and converts
the packet to
DestAddr = $Client
SourceAddr = $NatExternal
DestPort = $ClientEventPort
SourcePort = $RemoteAuxPort,
Nat also notes that this connection is established and records this
information in its mangle table.
From the above it is clear that Firebird events will traverse Nat.
It is also clear that FbServer.Firewall must allow traffic in both
directions on $RemoteAuxPort as must clients (otherwise connection
won't be established).
The client end of the connection can also be NATted with the same NAT
magic happening there. I don't propose to enumerate that end because
it just a mirror of the example given.
Caveats: I'm not sure which object (Client or Server) establishes the
event path.
The above is simplified so I could get my head around it.
I might have it completely wrong - I'm sure that someone will let me know.
Conclusion:
Firebird data and events can traverse NAT and firewalls if they are
configured to suit.
Firebird events are just data channels it is the dll or library that
reacts differently.
In effect the differences between Data connections and event
connections are
1) They use a different port
2) Events are handled by the library which then calls the client
application
3) Events are asynchonous.
Mick Arundell