Re: [masq] IP Port Forwarding
On 1 Feb 99, at 12:39, Chris Y. wrote about "[masq] IP Port Forwarding": | I am hoping that someone can help me out on what I might do in order to | fix this situation. I hope someone knowledgeable will jump in here, because I'd like to do the same kind of setup while migrating from ISDN to DSL. | I have a firewall with 3 NIC's in it. | | Eth0 - Is a high speed (dhcp based) cable modem connection (24.x.x.x) | Eth1 - ISDN Link (139.143.42.x) | Eth2 - Internal Lan (10.x.x.x) | | Eth0 is my default gateway for my firewall (masq) so that the desktops get | high speed net access. | | Eth1 is the IP address of my current mail server (which is moved to | 10.0.0.3). | | I have setup port forwarding on my eth1 interface for ports 25 110 (smtp | pop3) - 10.0.0.3 | | ipportfw -A -t 139.143.42.228/25 -R 10.0.0.3/25 | and the same for 110 Port forwarding initializes a masq table entry for the reply... | Now what happens (or seems to) is that the packet is passed through to the | mail server, but when the mailserver responds it sends it out the | firewalls default gw which of course is not a valid response to the | previous query. It seems to me it should not matter that the reply reaches the external client via different route. So if it doesn't work, it implies that the reply is being masqueraded with the IP associated with eth0, and the client sees an unexpected source IP. But shouldn't the masquerade entry set up by IPPORTFW cause the correct source address to be filled in? Another possibility is that masquerading is doing all it can, but your ISP (or an upstream router) is dropping the packets because they appear to be spoofed (technically, they *are* spoofed). | So I would like all items that are forwarded through the eth1 device to go | back out that device masq as 139.143.42.228. As for actually routing the masqueraded reply through the eth1 interface, is that even possible? Can the masquerade logic override the default route? |... - Fred Viles mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For daily digest info, email [EMAIL PROTECTED]
Re: [masq] IP Port Forwarding
Fred Viles [EMAIL PROTECTED] wrote: As for actually routing the masqueraded reply through the eth1 interface, is that even possible? Can the masquerade logic override the default route? This is a common misconception about IP Masq. (I'm not saying that you're having this misconception, I'm just saying that it's common.) The IP Masq rulesets might appear that they are controlling route behavior, but they do not. They merely modify route decisions after they have already been made. Once a routing decision has been made (via the route table), the masq rules can only decide whether it should, or should not happen, or whether to invoke masquerading when the route is taken. It's possible that masq isn't quite set up properly in the problem given. Perhaps the masq box is trying to masquerade in multiple directions, which makes the target machine unable to recognize its own reply (because it looks like a different machine). Just a guess, really. Anyway, the main issue is that, if you think the packets are going the wrong way, you have to fix the route table to do the right thing. You can't fix it in the masq rules; they can't change that behavior. If a machine is sending packets the wrong way, you'll have to teach it how to send them the right way intead. -- [EMAIL PROTECTED] (Fuzzy Fox) || "Nothing takes the taste out of peanut sometimes known as David DeSimone || butter quite like unrequited love." http://www.dallas.net/~fox/ || -- Charlie Brown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For daily digest info, email [EMAIL PROTECTED]
Re: [masq] [masq] IP Port Forwarding
Thanks for the quick reply. On 2 Feb 99, at 1:09, Fuzzy Fox wrote about "Re: [masq] IP Port Forwarding": | Fred Viles [EMAIL PROTECTED] wrote: | | As for actually routing the masqueraded reply through the eth1 | interface, is that even possible? Can the masquerade logic override | the default route? |... | Once a routing decision has been made (via the route table), the masq | rules can only decide whether it should, or should not happen, or | whether to invoke masquerading when the route is taken. Yes, that's implied by the fact that the forwarding/masquerade rules are associated with the outgoing interface. So this is also true when a packet matches an existing entry in the masq table, right? But in theory it might still be possible to explicitly direct the packet to the interface associated with the masq IP address from the table? It would have to have a gateway IP configured, but not be the default route. Obviously the current masq code can't do this, of course. | It's possible that masq isn't quite set up properly in the problem | given. Perhaps the masq box is trying to masquerade in multiple | directions, which makes the target machine unable to recognize its own | reply (because it looks like a different machine). Just a guess, | really. It would be really nice if masq could handle this case and we just have to configure it right. But I don't think so. The problem is that while routing only allows for one default route to the outside, there are really two valid routes. So thanks to IPPORTFW, connections can be made from the outside world to masq'ed machines via either interface, and the replies can't similarly be routed back via either interface. | Anyway, the main issue is that, if you think the packets are going the | wrong way, you have to fix the route table to do the right thing. You can't, at least in 2.0.x kernels. You might be able to get policy routing to do the right thing in 2.2.x kernels, depending on your situation. That might help Chris, who would probably be happy to unconditionally route source port 25 and 110 traffic from his email server to his ISDN link. | You | can't fix it in the masq rules; they can't change that behavior. If a | machine is sending packets the wrong way, you'll have to teach it how to | send them the right way intead. Dynamically, maybe? Patch IPPORTFW to add a route for the connecting host, and patch IPMASQ to remove it again when the masq entry is deleted? Wonder what that would do to performance... |... - Fred Viles mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For daily digest info, email [EMAIL PROTECTED]
[masq] IP Port Forwarding
Hi, I am hoping that someone can help me out on what I might do in order to fix this situation. I have a firewall with 3 NIC's in it. Eth0 - Is a high speed (dhcp based) cable modem connection (24.x.x.x) Eth1 - ISDN Link (139.143.42.x) Eth2 - Internal Lan (10.x.x.x) Eth0 is my default gateway for my firewall (masq) so that the desktops get high speed net access. Eth1 is the IP address of my current mail server (which is moved to 10.0.0.3). I have setup port forwarding on my eth1 interface for ports 25 110 (smtp pop3) - 10.0.0.3 ipportfw -A -t 139.143.42.228/25 -R 10.0.0.3/25 and the same for 110 Now what happens (or seems to) is that the packet is passed through to the mail server, but when the mailserver responds it sends it out the firewalls default gw which of course is not a valid response to the previous query. So I would like all items that are forwarded through the eth1 device to go back out that device masq as 139.143.42.228. I don't know if you have any ideas on what I could do to make this work, I would love any help. Chris +---+---+ | Chris Yeo| URL: http://www.biking.org | | Computer Consultant | Email: [EMAIL PROTECTED] | +---+---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For daily digest info, email [EMAIL PROTECTED]
