Skip to contentSkip to conversation

COuple questions regarding ppp

DISCUSSION [email protected] 2 participants 4 messages Sep 17, 2010 PPP protocol drivers and compressors

lore
Share & tools
lore
#0 lore raw

Hello

We had a customer, call them BT. They set up a PPP server for us, so that I would do a ppp connection from my machine (Linux) to their's it would establish a connection. My machine is a 192 and they set up a remote IP address for me something like 10.1.1.16 or something. Their local network was 10.0.0.0/8 so I did an ip route replace 10.0.0.0/8 dev ppp0 or something like that. Then I could route to their machines from mine.

Now, I am setting up ppp. I have a client (call it florida) that people from here will use at a trade show in florida. I am setting up a server (call it illinois). I succesfully established a connection from florid to illinois. Got an IP of the following:
inet addr:192.168.0.1 P-t-P:192.168.0.234 Mask:255.255.255.255
(this on the server. Client is reversed of course). On the client (florida) is also a 192 network. The illinois machine has no 192 network on it, so I did an ip route replace 192.168.5/0 dev ppp0. When I try from illinois to ssh to 192.168.5.191 (which I can do from florida as it is the same network) it times out and cannot find a route. I did do the sysctl on each machine to set net.ipv4.ip_forward to 1. Is there something else I am not doing that I need to? Yes and I know I am trying to route from ppp server to client which is opposite of BT. And yes I can ssh to 192.168.0.234 and even 192.168.5.65 which is the IP address of florida.

The other question. Both machines are in my control and are Linux. florida is CentOS 4.5 and flordia just says redhat release 5. Anyway right now I have no encryption. Not sure it is necessary but I would feel better. But any combination of requires and refuses I try results in SIGUSR1 on the client (florida) side. What is a good configuration to have at both sides so packets are encrypted? This is not super duper top secret info so a lower encryption method would be OK.

#1 lore raw
Quoted 4 lines · On 09/17/10 09:34, [email protected] wrote:

We had a customer, call them BT. They set up a PPP server for us, so that I would do a ppp connection from my machine (Linux) to their's it would establish a connection. My machine is a 192 and they set up a remote IP address for me something like 10.1.1.16 or something.

"192" isn't a type of machine I recognize, so I'm going to assume that you meant that you have a local network (perhaps Ethernet) configured for an address in the RFC 1918 private address space 192.168.0.0/16.

Quoted 9 lines

Their local network
was 10.0.0.0/8 so I did an ip route replace 10.0.0.0/8 dev ppp0 or something like that. Then I could route to their machines from mine.

Now, I am setting up ppp. I have a client (call it florida) that people from here will use at a trade show in florida. I am setting up a server (call it illinois). I succesfully established a connection from florid to illinois. Got an IP of the following:

   inet addr:192.168.0.1  P-t-P:192.168.0.234  Mask:255.255.255.255

Continuing with my assumption above, that link should be using proxy-ARP, because the remote address is (probably) in the same subnet as the assumed local network above. (Maybe ... there's a lack of details here.)

Quoted 2 lines

(this on the server. Client is reversed of course). On the client (florida) is also a 192 network.

That's bad news unless you've got distinct subnets. I hope you do.

There's unfortunately a lack of detailed information here about the networks and interfaces in use.

Quoted 4 lines

The illinois machine has no 192 network
on it, so I did an ip route replace 192.168.5/0 dev ppp0. When I try from illinois to ssh to 192.168.5.191 (which I can do from florida as it is the same network) it times out and cannot find a route.

What does 192.168.5/0 mean? Did you perhaps intend 192.168.5.0/24 instead? It sounds like you added a host route for 192.168.5.0 (a single IP address) rather than the required network route for the remote subnet.

"netstat -nr" on each of the machines and a simple ASCII-art picture of the network would help greatly.

The questions you're asking sound like straightforward Linux routing questions, and not issues specifically related to PPP. You might do better on a different mailing list.

Quoted 5 lines

I did do the
sysctl on each machine to set net.ipv4.ip_forward to 1. Is there something else I am not doing that I need to? Yes and I know I am trying to route from ppp server to client which is opposite of BT. And yes I can ssh to 192.168.0.234 and even 192.168.5.65 which is the IP address of florida.

Which indicates that there's no PPP issue here, but rather a routing configuration problem.

For what it might be worth, I'm a big fan of dynamic routing protocols (such as RIP and OSPF) because they take care of all the route computation problems for you, rather than forcing you to configure every single machine in your network with an obscure list of static routes. There's a downside (you have to learn about setting up routing protocols), but the upside is better manageability in the longer term.

Quoted 7 lines

The other question. Both machines are in my control and are Linux. florida is CentOS 4.5 and flordia just says redhat release 5. Anyway right now I have no encryption. Not sure it is necessary but I would feel better. But any combination of requires and refuses I try results in SIGUSR1 on the client (florida) side. What is a good configuration to have at both sides so packets are encrypted? This is not super duper top secret info so a lower encryption method would be OK.

"It depends."

I would recommend first investigating the use of higher-level encryption mechanisms, such as IPsec and SSL, rather than something at the PPP level. There's a lot to be said for end-to-end security, though it certainly takes a lot more effort to get right.

If you insist on using encrypted PPP links, there's not much to choose from right now. On some platforms, you might be able to get Microsoft's proprietary MPPE to work. Otherwise, you've got the source, so go to town on it. :-/

If you have specific problems (I don't recognize SIGUSR1 as any sort of error that pppd ever produces; it's a signal that the daemon recognizes and uses to increase debug level, and not an error), you should post complete copies of your configuration files and your debug logs. Without details, it's not really possible to come up with a solution.

Signature · 1 line
James Carlson         42.703N 71.076W         <[email protected]>
#2 lore raw
In reply to [email protected]

Sorry. By 192 I meant 192.168.5.0/24 network machine. I fixed the problem by adding

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

as for MPPE, that is what I am trying to get to work. I will send output again (if anyone still wants it ;-) ). I have to recreate it.

===

Quoted 2 lines

would establish a connection. My machine is a 192 and they set up a remote IP address for me something like 10.1.1.16 or something.

"192" isn't a type of machine I recognize, so I'm going to assume that you meant that you have a local network (perhaps Ethernet) configured for an address in the RFC 1918 private address space 192.168.0.0/16.

Quoted 9 lines

Their local network
was 10.0.0.0/8 so I did an ip route replace 10.0.0.0/8 dev ppp0 or something like that. Then I could route to their machines from mine.

Now, I am setting up ppp. I have a client (call it florida) that people from here will use at a trade show in florida. I am setting up a server (call it illinois). I succesfully established a connection from florid to illinois. Got an IP of the following:

   inet addr:192.168.0.1  P-t-P:192.168.0.234  Mask:255.255.255.255

Continuing with my assumption above, that link should be using proxy-ARP, because the remote address is (probably) in the same subnet as the assumed local network above. (Maybe ... there's a lack of details here.)

Quoted 2 lines

(this on the server. Client is reversed of course). On the client (florida) is also a 192 network.

That's bad news unless you've got distinct subnets. I hope you do.

There's unfortunately a lack of detailed information here about the networks and interfaces in use.

Quoted 4 lines

The illinois machine has no 192 network
on it, so I did an ip route replace 192.168.5/0 dev ppp0. When I try from illinois to ssh to 192.168.5.191 (which I can do from florida as it is the same network) it times out and cannot find a route.

What does 192.168.5/0 mean? Did you perhaps intend 192.168.5.0/24 instead? It sounds like you added a host route for 192.168.5.0 (a single IP address) rather than the required network route for the remote subnet.

"netstat -nr" on each of the machines and a simple ASCII-art picture of the network would help greatly.

The questions you're asking sound like straightforward Linux routing questions, and not issues specifically related to PPP. You might do better on a different mailing list.

Quoted 5 lines

I did do the
sysctl on each machine to set net.ipv4.ip_forward to 1. Is there something else I am not doing that I need to? Yes and I know I am trying to route from ppp server to client which is opposite of BT. And yes I can ssh to 192.168.0.234 and even 192.168.5.65 which is the IP address of florida.

Which indicates that there's no PPP issue here, but rather a routing configuration problem.

For what it might be worth, I'm a big fan of dynamic routing protocols (such as RIP and OSPF) because they take care of all the route computation problems for you, rather than forcing you to configure every single machine in your network with an obscure list of static routes. There's a downside (you have to learn about setting up routing protocols), but the upside is better manageability in the longer term.

Quoted 7 lines

The other question. Both machines are in my control and are Linux. florida is CentOS 4.5 and flordia just says redhat release 5. Anyway right now I have no encryption. Not sure it is necessary but I would feel better. But any combination of requires and refuses I try results in SIGUSR1 on the client (florida) side. What is a good configuration to have at both sides so packets are encrypted? This is not super duper top secret info so a lower encryption method would be OK.

"It depends."

I would recommend first investigating the use of higher-level encryption mechanisms, such as IPsec and SSL, rather than something at the PPP level. There's a lot to be said for end-to-end security, though it certainly takes a lot more effort to get right.

If you insist on using encrypted PPP links, there's not much to choose from right now. On some platforms, you might be able to get Microsoft's proprietary MPPE to work. Otherwise, you've got the source, so go to town on it. :-/

If you have specific problems (I don't recognize SIGUSR1 as any sort of error that pppd ever produces; it's a signal that the daemon recognizes and uses to increase debug level, and not an error), you should post complete copies of your configuration files and your debug logs. Without details, it's not really possible to come up with a solution.

Signature · 1 line
James Carlson         42.703N 71.076W         <[email protected]>
#3 lore raw
In reply to [email protected]

Oh and I got mppe to work finally. I just misunderstood the chap-secrets file.

-----Original Message-----
From: James Carlson [mailto:[email protected]]
Sent: Friday, September 17, 2010 09:10 AM
To: [email protected]
Cc: 'ppp Linux'
Subject: Re: COuple questions regarding ppp

Quoted 4 lines · On 09/17/10 09:34, [email protected] wrote:

We had a customer, call them BT. They set up a PPP server for us, so that I would do a ppp connection from my machine (Linux) to their's it would establish a connection. My machine is a 192 and they set up a remote IP address for me something like 10.1.1.16 or something.

"192" isn't a type of machine I recognize, so I'm going to assume that you meant that you have a local network (perhaps Ethernet) configured for an address in the RFC 1918 private address space 192.168.0.0/16.

Quoted 9 lines

Their local network
was 10.0.0.0/8 so I did an ip route replace 10.0.0.0/8 dev ppp0 or something like that. Then I could route to their machines from mine.

Now, I am setting up ppp. I have a client (call it florida) that people from here will use at a trade show in florida. I am setting up a server (call it illinois). I succesfully established a connection from florid to illinois. Got an IP of the following:

   inet addr:192.168.0.1  P-t-P:192.168.0.234  Mask:255.255.255.255

Continuing with my assumption above, that link should be using proxy-ARP, because the remote address is (probably) in the same subnet as the assumed local network above. (Maybe ... there's a lack of details here.)

Quoted 2 lines

(this on the server. Client is reversed of course). On the client (florida) is also a 192 network.

That's bad news unless you've got distinct subnets. I hope you do.

There's unfortunately a lack of detailed information here about the networks and interfaces in use.

Quoted 4 lines

The illinois machine has no 192 network
on it, so I did an ip route replace 192.168.5/0 dev ppp0. When I try from illinois to ssh to 192.168.5.191 (which I can do from florida as it is the same network) it times out and cannot find a route.

What does 192.168.5/0 mean? Did you perhaps intend 192.168.5.0/24 instead? It sounds like you added a host route for 192.168.5.0 (a single IP address) rather than the required network route for the remote subnet.

"netstat -nr" on each of the machines and a simple ASCII-art picture of the network would help greatly.

The questions you're asking sound like straightforward Linux routing questions, and not issues specifically related to PPP. You might do better on a different mailing list.

Quoted 5 lines

I did do the
sysctl on each machine to set net.ipv4.ip_forward to 1. Is there something else I am not doing that I need to? Yes and I know I am trying to route from ppp server to client which is opposite of BT. And yes I can ssh to 192.168.0.234 and even 192.168.5.65 which is the IP address of florida.

Which indicates that there's no PPP issue here, but rather a routing configuration problem.

For what it might be worth, I'm a big fan of dynamic routing protocols (such as RIP and OSPF) because they take care of all the route computation problems for you, rather than forcing you to configure every single machine in your network with an obscure list of static routes. There's a downside (you have to learn about setting up routing protocols), but the upside is better manageability in the longer term.

Quoted 7 lines

The other question. Both machines are in my control and are Linux. florida is CentOS 4.5 and flordia just says redhat release 5. Anyway right now I have no encryption. Not sure it is necessary but I would feel better. But any combination of requires and refuses I try results in SIGUSR1 on the client (florida) side. What is a good configuration to have at both sides so packets are encrypted? This is not super duper top secret info so a lower encryption method would be OK.

"It depends."

I would recommend first investigating the use of higher-level encryption mechanisms, such as IPsec and SSL, rather than something at the PPP level. There's a lot to be said for end-to-end security, though it certainly takes a lot more effort to get right.

If you insist on using encrypted PPP links, there's not much to choose from right now. On some platforms, you might be able to get Microsoft's proprietary MPPE to work. Otherwise, you've got the source, so go to town on it. :-/

If you have specific problems (I don't recognize SIGUSR1 as any sort of error that pppd ever produces; it's a signal that the daemon recognizes and uses to increase debug level, and not an error), you should post complete copies of your configuration files and your debug logs. Without details, it's not really possible to come up with a solution.

Signature · 1 line
James Carlson         42.703N 71.076W         <[email protected]>