On 05/13/2011 05:22 AM, Mr Dash Four wrote: > >>> OK! One more query: On one of my machines I do SNAT. What source >>> should I specify when using this in tcrules - the original IP >>> address or the one I changed it to? In other words, what should I >>> use: the "SOURCE" or the "ADDRESS" column (from the masq file) >>> when creating rules in tcrules (also bearing in mind that I use >>> classes and not marks)? >>> >> >> There is no Netfilter hook called after the SOURCE address has been >> re-written by SNAT/MASQUERADE rules. So all netfilter rules must >> use the original SOURCE address. >> > Erm, I don't quite understand this! The masquerading I use is to > change the source address to "appear" as if it originated from > another interface and then transmit packets over the wire using that > interface. This has been working for years for me, though it wasn't > "traffic-shaped" properly. The problem I now have is how to classify > it, because it originates on one interface and it is transmitted > using another (with its source address changed). Here is an example > with which I will try to illustrate this: > > eth0 is 10.1.1.12 and is on the 10.1.1.0/24 net eth1 is 10.1.2.7 and > is on the 10.1.2.0/24 net > > Both interfaces are on the same machine. The stream I am interested > in originates on 10.1.1.12 and is destined for the outside world, say > to 212.58.254.251 port ranges from 1193 to 2193 via eth1 (10.1.2.7).
What do you mean by originates on 10.1.1.12? Do you mean that some host
connected to 10.1.1.2 (say, 10.1.1.99) creates the packet? I'll assume so.
> So, I use the following statements in masq:
>
> "eth1::212.58.254.251 10.1.1.12 10.1.2.7 udp 1193:2193" and
> "eth1::212.58.254.251 10.1.1.12 10.1.2.7 tcp 1193:2193".
>
Hmm -- If my assumption is correct, then you would need something like:
eth1:212.58.254.251 10.1.1.12/24 10.1.2.7 udp 1193:2193
eth1:212.58.254.251 10.1.1.12/24 10.1.2.7 tcp 1193:2193
> Please note that the routing table is already altered in a way to
> correctly route this stream (as I pointed out - it has been working
> for me for years, though that traffic was not "shaped" properly).
> Also, the traffic is in both directions (hence the use of port
> ranges!), so I need to "shape" it using tcrules as well as tcfilters.
>
> Now, the problem I face is how do I classify this traffic? Should I
> create and use a class belonging to eth0 or eth1 given that the
> actual flow will *never* pass through eth0? In other words, do I use
> "eth0:12 - $FW 212.58.254.251 ...." or "eth1:12 - $FW 212.58.254.251
> ...."?
>
> What about tcfilters - the traffic originating from 212.58.254.251
> arrives at eth1:10.1.2.7, but is actually destined for 10.1.1.12 - do
> I use ifb0-related classes (assuming ifb0 is derived from eth0) or do
> I define classes using ifb1?
As far as traffic shaping goes, outbound traffic will pass through
ifb0 eth1
In both cases, the source IP will be 10.1.1.99 and the destination
address will be 212.58.254.251.
Inbound traffic will pass through
ifb1 source IP will be 212.58.254.25 and dest IP will be
10.1.2.7. Destination port number may have been changed
if it was a duplicate of another active proto/port pair.
eth0 source IP will be 212.58.254.25 and dest IP will be
10.1.1.99
Now, if you really mean that an application on the Shorewall box binds
its inet socket to 10.1.1.12 and connects/sends to 212.58.254.25, then
outbound traffic will not go through ifb0 and inbound traffic will not
go through eth0.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
