Ok so after posting this question last night night I continued to do some research the only real solution I came across seems to have taken care of the problem.
Disabling TSO, GSO and GRO using ethtool:
ethtool -K eth0 gso off gro off tso off
According to a post found here: http://ehc.ac/p/e1000/bugs/378/
From what I understand this will or can cause a ...
IPtables has a list of rules, and for each packet, it checks the list of rules in order. Once a rule is found that matches the packet and specifies a policy (ACCEPT, REJECT, DROP), the fate of the matching packet is determined; no more rules are examined.
This means that the order in which you run commands is important. When you use iptables -A, you add a ...
Unfortunately, this is a well-known shortcoming of the DNS protocol. There is no record type defined within the DNS standards that will allow you to alias the apex of a domain. Many people assume that CNAME records can be used to accomplish this but there are technical reasons why they cannot.
Many DNS providers implement custom (read: fake) DNS record ...
The -A flag tells iptables to append the rule to the chain, meaning it ends up under your REJECT rule, and since the first rule matches, it's never used.
You list your rules with iptables -L FORWARD and you will see this yourself. To get rid of the rule you added, run
iptables -D FORWARD -j REJECT
Until there are no more such rules in the chain.
Another possible reason is connection sharing: one might already be logged in on the other host without agent forwarding and connection sharing enabled. The second login with ssh -A (or equivalently specified in the config file) via the shared connection will silently ignore the -A flag. Only after completely logging out or disabling connection sharing for ...
You shouldn't have a reason to forward to other AD servers, as DNS should be replicating between them already.
The only reason I can think of for this would be if you wanted only one DNS server to be the one querying the internet for non-authoritative FQDNs.
Usually the forwarders (used to resolve non-authoritative lookups) are set to external DNS servers ...
Disabling Enhanced C1 (C1E) in the BIOS fixed it for me.
Not sure if the lower power state of C1E is messing with the driver, or that there's an oops in the driver when the processor is in this state.
Anyway, problem solved.
Summary: In short, you can't have the record you want, and your DNS host is doing things The Right Way.
Explanation: It is a violation of the DNS standadards to have a CNAME (alias record / forward record) at zone apex (the empty name at the front of the zone).
The reason for this is a CNAME record cannot have the name portion conflict with any record ...
I had problem with sshd server rejecting agent forwarding request because of no space left in /tmp. This was because sshd needs to create socket in /tmp. Cleaning disk up resolved my issue.
ssh -v said back then:
debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device
You can always just ssh to localhost with agent forwarding instead of using sudo:
ssh -A otheruser@localhost
Disadvantage is that you need to log in again, but if you're using it in a screen/tmux tab, that's only a one time effort, however, if you disconnect from the server, the socket will (of course) be broken again. So it's not ideal if you can't keep ...
Is there any way I can "relay" mail traffic?
Is there any way this is possible, and if so how?
This is generally known as a mail "smarthost", and it is a very frequent use case.
You'll need to choose an MTA (choose postfix), and then consult that MTA's documentation for how to set up a smarthost relay.
the missing part from your configuration is described here: https://www.linux-kvm.org/page/Networking. You have to add another netdev with new address like so:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
Here is what I do specifically for localhost forwarding:
iptables -t nat -A OUTPUT -m addrtype --src-type LOCAL --dst-type LOCAL -p tcp --dport 3306 -j DNAT --to-destination ip.ip.ip.ip
iptables -t nat -A POSTROUTING -m addrtype --src-type LOCAL --dst-type UNICAST -j MASQUERADE
sysctl -w net.ipv4.conf.all.route_localnet=1
Make sure you substitute ip.ip.ip....
As far as I know, you just can't. Transports are different, iptables can't do that. However, you can setup a process that will suck data from a socket and feed it into another.
You can try that on your work server :
socat TCP4-LISTEN:5600,fork,su=nobody TCP6:[home_server_ipv6_address]:5600
I fixed this with postsrsd by following this guide: https://www.mind-it.info/forward-postfix-spf-srs/
Download and compile the software
sudo make install
Add postfix configuration parameters for postsrsd
sudo postconf -e "...
You need to use the PREROUTING chain to forward port :
iptables -t nat -A PREROUTING -p udp -i eth0 -d 192.168.1.2 --dport 1003 -j DNAT --to-destination 192.168.1.2:1004
By the way, it seems filter is happening directly on the target host, so you could use REDIRECT in that case :
iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.2 -p udp --dport 1003 -j ...
ssh -L 54320:Server_A:5432 user@Server_B
looks good, but then when doing this:
psql -p 54320 -d db_name -U user
the ssh tunnel is not used, because by default on Unix, psql connects to a Unix domain socket, like suggested by the error message you mention ("...accepting connections on Unix domain socket...")
You're just missing a -h ...
Combining information from the other answers I came up with this:
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i
I like this because I don't need to edit sudoers file.
Tested on Ubuntu 14.04 (had to install acl package).
Not knowing how your environment is set up and what your goals are I'll risk suggesting that you shouldn't have your DC/DNS servers using any other DC/DNS servers as forwarders.
The only scenario where I've seen internal DNS servers using other internal DNS servers as forwarders is when the security policy restricts outbound DNS traffic to a few secured DNS ...
Disabling only TCP Segmentation Offload (TSO) does the trick for me.
ethtool -K eth0 tso off
Note: It does not seem to be necessary to also disable Generic Receive Offload (GRO) and Generic Segmentation Offload (GSO), as it is recommended by various sources. As far as I learned, these are implemented purely in software, and should be safe. Don't sacrifice ...
Router advertisements are not supposed to be forwarded. So when you find that they are not being forwarded, then at least that part is working as intended.
You are supposed to be running your own router advertisement daemon in your router, such that it advertises itself to the LANs.
You should have three separate /64 prefixes for your three LANs. So you ...
For the benefit of other googlers who also arrived at this question:
Incorrect whitespace in a ~/.ssh/config file can also cause some head scratching.
I recently helped out one of my co-workers who had this:
host foobar ForwardAgent yes
instead of this:
I've also run into instances where missing ...
First of all, in my point of view, I think you should first clearly understand the distinction between forwarding and routing, which is often neglected. According to the book Computer Networks in page 240 by Lary L.Peterson, forwarding is a series of actions the router will take once receives a packet, including looking at its destination address, consulting ...
One simple indication is to look to see if a valid looking DISPLAY variable is set. If no display is set, you can be almost certain forwarding is not working properly.
$ export | grep DISPLAY
declare -x DISPLAY="localhost:10.0"
Do not forward spam. Reject it or Drop it before forwarding.
GMail hates spam as much as you do. So Gmail began to rate limiting your server because your server who throwing the spam upon them.
The article that you refer to was talking about domain not IP address. Both was different factors to consider when comes to email reputation.
We need to intercept the P2 connection to localhost TCP/50000 and forward it to the PROXY listening on TCP/8080 - The PROXY has to be configured to forward the request to LOCALHOST TCP/5000.
For this to work we need to activate the forwarding of localhost ports to IPTABLES, changing following system parameter:
sysctl -w net.ipv4.conf.all.route_localnet=1