>> 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. > No! As I pointed above, the machine in question has two interfaces - eth0 with ip address 10.1.1.12 (which is part of the 10.1.1.0/24 internal subnet) and another interface - eth1 - with ip address 10.1.2.7 (which is part of a separate subnet - 10.1.2.0/24).
The traffic originates on eth0 - it is created by a program, which listens on that address - "10.1.1.12:*" and that program hooks/uses port ranges 1193 to 2193. When it sends traffic destined to, say, 212.58.254.251 using the same destination port ranges (1193-2193) that traffic gets SNATed and routed through eth1 on 10.1.2.7. In other words after SNAT is done it "appears" as if it comes from 10.1.2.7. >> 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 > No! I only need traffic originating on eth0 with that single ip address - 10.1.1.12 to be SNATed to 10.1.2.7. The rest of the traffic to/from 10.1.1.0/24 is left intact and is processed in the usual manner. >> 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. > I don't see where ifb0 comes from except in inbound traffic (may be) - it is never involved as I think the traffic flow goes like this: (outbound) eth0 -> SNAT -> eth1 -> 212.58.254.251 and (inbound) 212.58.254.251 -> ifb1 -> (SNAT "return "leg") -> ifb0 > 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 > > Nope! I don't use 10.1.1.99 at all. > 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. > That is exactly what I have! So, do I have this then: (outbound) eth0 -> 212.58.254.251, but passing through eth1 and (inbound) 212.58.254.251 -> ifb0, but passing through ifb1? If so, which classes should I use for the purpose of defining my traffic shaping? The other "unknown" for me is, assuming I need to use eth0 class for outbound traffic, that presumably needs to be accounted for from the eth0 quota and that would be wrong, I think, as that traffic *never* actually passes through eth0 at all as it is SNATed and actually goes via eth1, isn't it? A similar point I think is valid for inbound traffic as well - do I use ifb0 or ifb1 classes to "capture" this traffic in tcfilters? ------------------------------------------------------------------------------ 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
