> The advice to add:
> net.ipv4.ip_forward = 1
> to /etc/sysctl.conf only takes effect after the next
> reboot. If you want to change this on the fly you can:
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
[root@localhost ~]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
> > it says iptables and has this part:
> > # Forward all packets from eth1 (internal network) to
> eth0 (the public internet)
> > iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
> > # Forward packets that are part of existing and
> related connections from eth0 to eth1
> > iptables -A FORWARD -i eth0 -o eth1 -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> > # Enable SNAT functionality on eth0. a.b.c.d are
> generally the ip of the eth0
> > iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -o
> eth0 -j SNAT --to-source a.
> >
> > I added everything here except last line "Enable
> SNAT", I do not know what that means, I know it is
> close. I can ping the host machine, it gets an ip, it gets
> DNS, and all, but cannot surf :(
>
> Anywhere you send packets needs some way to get the
> response back to the sender. One way to do this is to plan
> things so all of your private subnets are unique and add
> routes toward the gateway interfaces for everything else.
> Another way is to NAT the source address as it goes out the
> already-known interface. That way the rest of the world
> does not need to know about your new private subnet. As a
> packet goes out, the source address of the client will be
> replaced with the address of the forwarding interface and
> the host performing this will maintain a table of
> connections to do the reverse mapping as the reply packets
> come back. If you tcpdump your eth0 interface now,
> you'll probably see packets being forwarded out but
> nothing coming back because the rest of the net/world
> doesn't know the route back. When you add the SNAT, it
> will look like the host machine itself to the rest of the
> world. The argument to -s is the range of original
> addresses to replace, -o is the outbound interface, and
> --to-source is the IP of the outbound interface on the host.
>
> -- Les Mikesell
> lesmikesell@xxxxxxxxx
The rest of the local network does not have to know about this one, but I have not done this before, I have tried but not succeeded, now I know that I am close, but not there yet. Just need a few more hints/advice and it will work :)
This appears to have been removed, the rules to forward using iptables :(
[root@localhost ~]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
[root@localhost ~]#
Thank you very much for trying to help.
Now there's also ip6tables, but I do not want to go there yet :(
Regards,
Antonio
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
